+1 for opening to all. I think if anyone wants to abuse anything they can wreak much havoc by abusive comments etc. It's a far more "attractive" target than triaging the issue. And we can always ask INFRA to block abusive users: https://github.blog/2016-04-04-organizations-can-now-block-abusive-users/
J. On Thu, Aug 20, 2020 at 3:34 PM Rob Tompkins <chtom...@gmail.com> wrote: > > > > On Aug 20, 2020, at 7:06 AM, Mark Thomas <ma...@apache.org> wrote: > > > > If you mean "grant the triage role to anyone with a GitHub account" then > +1. > > +1 as well here. Or anyone that minimally shows any interest. We should > proactively ask people that are contributing if they would like such status. > > -Rob > > > > > If you mean create a new level between contributor (i.e. anyone) and > > committer then -1. > > > > If you go back (quite a few years) to when Bugzilla was the main issue > > tracker for ASF projects it was (and still is for those projects that > > use it - httpd, Tomcat etc) configured so that any user with an account > > could open, edit, label, close etc any bug. > > > > Over time many projects seem to have adopted a more restrictive approach > > to issue management. I think that is partly due to the tools being used > > being more restrictive by default and partly due to a more corporate > > mindset prevailing in some projects that prefers technical barriers to > > social barriers. > > > > I am strongly of the view that social barriers are better for > > communities than technical barriers. A lot of my early contributions to > > Tomcat were around triaging open issues. I could only do that because > > access to BZ issues was managed via social controls rather than > > technical ones. > > > > Experience with BZ suggests that opening up the Github triage role to > > all will attract a few idiots from time to time but they can easily be > > banned and the benefits of attracting new contributors far outweigh the > > costs of idiot management. > > > > Mark > > > > > > On 20/08/2020 10:20, Paul Angus wrote: > >> Hi Members, > >> > >> One of our (CloudStack) comitters has come with a great idea to increase > >> project contributions... > >> > >> Traditionally Github has been very binary, you're either a commiter and > you > >> can write to a Repo and perform Issue and Pull Request admin (like add > >> labels, change status, etc), or you aren't a comitter and 'sucks to be > you'. > >> > >> Githib has introduced a 'Triage' role which bridges the gap. The Triage > >> role, allows issue and pull request admin, but still blocks writing to > the > >> actual code. [1] > >> > >> I guess we'd need a mechanism to control/add contributors to the Triage > >> team per project, kinda like Karma for Confluence. > >> > >> I think that would be a great stepping stone for contributors to get > more > >> involved in projects, so I'd like to gather support from other projects > and > >> the ASF 'elders' for the principle. > >> > >> Many thanks > >> > >> Paul Angus > >> > >> [1] > >> > https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > For additional commands, e-mail: dev-h...@community.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > > -- +48 660 796 129
