Promises about the future about Github’s roadmap is understandably difficult to make, besides by a very small number of people at the top. I don’t think this is the expectation. But visibility into past failure to address these concerns and the current status is long overdue. I assume when these maintainers reached out in private channels, they were equally detailed, and have waited years.
At present, I’m not sure how this response is different from the "empty response" that motivated the publication of this document in the first place, except that this response is also public. Comments like "happy to take a look into these issues", "considered in how future work is planned" and "ensure the right eyeballs are on this" uses a lot of words to say nothing. If the community department is not the right place, maybe it’s time to walk over to where the the product group sits and ask. They probably read Hacker New too.
I’ll also highlight a possible theory: the right people at Github have already looked at these requests and decided that is not what Github Issues is for. Perhaps Issues is prioritized for the masses, not the small minority of very popular projects (but not resourceful enough that they have staff). Each of these feature requests do add friction (if only in complexity) and the majority of projects that do not need and should not utilize them. Hopefully someone at Github will quash this theory but it is consistent with events so far.
GitHub has settings for individual repos. People can opt to turn the issue tracker off completely.
Why not have the option to enable issue voting? It could be as easy as stars for issues.
Custom issue instructions would be trivial to tuck away in the settings page or associate with a specially named markdown file. They turn a wiki on by default, but you can't instruct users about the info you expect in their issue on the page where they create the issue. Documentation is very effective when it is inline with the system it is describing.
Custom issue fields with validation is a little more complex. Punt.
At present, I’m not sure how this response is different from the "empty response" that motivated the publication of this document in the first place, except that this response is also public. Comments like "happy to take a look into these issues", "considered in how future work is planned" and "ensure the right eyeballs are on this" uses a lot of words to say nothing. If the community department is not the right place, maybe it’s time to walk over to where the the product group sits and ask. They probably read Hacker New too.
I’ll also highlight a possible theory: the right people at Github have already looked at these requests and decided that is not what Github Issues is for. Perhaps Issues is prioritized for the masses, not the small minority of very popular projects (but not resourceful enough that they have staff). Each of these feature requests do add friction (if only in complexity) and the majority of projects that do not need and should not utilize them. Hopefully someone at Github will quash this theory but it is consistent with events so far.