On Sat, 22 Aug 2020 at 14:32, Rob Tompkins <chtom...@gmail.com> wrote: > > > > > On Aug 20, 2020, at 9:34 AM, 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. > > To slow the number of “triage” users and stem spamming, might we necessitate > only a CLA being signed as a barrier to entry? That way people have to do > something to get the status, but still anyone can sign a CLA.
That could be a lot of work for the Secretarial team. I don't think a CLA is necessary here. If there is to be some barrier to entry, it needs to be managed at project level to spread the workload. > -Rob > > > > > -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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
