[octref]

I hope GitHub could add some features to help Open Source maintainers. Allow adding contributors with issue triaging privileges is an obvious one. Required fields (link to repro, software version) could be really helpful too.

Currently people have to work around these issues in awkward ways, like creating a whole organization just to grant issue triaging privileges or redirecting people off GitHub for filing issues with required fields [0]. Those workarounds run into limits quickly.

[0]: https://new-issue.vuejs.org/?repo=vuejs/vue

[steveklabnik]

They did add https://blog.github.com/2016-03-29-saved-replies/ a few years back which would have saved my "copy/paste" stuff in the post.

I have long had chats with Hubbers over the years about the privilege thing, and one of the hardest parts is the UI challenge. That is, you can do this, but can you do it in a way that's not maddeningly complex? It's unclear.

[octref]

> that's not maddeningly complex

I'm not sure what's complex. Adding one more option "Triaging" here[0] doesn't seem complex.

I'm working at VS Code and now we are trying to make a bot that would add a label if someone (from a whitelist) types `/label bug` (same for marking duplicates). The fact that we have to go this far for letting community contributors assign labels to issues is more maddening to me.

See an example here: https://github.com/Microsoft/vscode/issues/62016#issuecommen....

[0]: https://user-images.githubusercontent.com/4033249/47674432-8...

[steveklabnik]

Yeah, we do that with Rust too.

Sure, if the perm is solely "traige issues", maybe that's fine, but what is the exact level of granularity for this kind of thing?

I don't mean it's impossible, just that it's not completely simple, and there's work to do to sort out the details. I also have never seen what dotcom looks like, so I have no idea how hard these things are to implement, either. Sometimes simple features can be rough to implement, especially in large, legacy Rails apps...