Re: Triage role on Github
> On Aug 20, 2020, at 12:48 PM, Jacques Le Roux > wrote: > > Le 20/08/2020 à 15:08, Bertrand Delacretaz a écrit : >> On Thu, Aug 20, 2020 at 3:01 PM Harbs wrote: >>> I also don’t see any harm in making triage rights open to all >> I suspect creative minds might find a way to spam us with this if it's >> "open to all" ? > > From my experience it always ends like this... > > >> >> For our wikis I think we generally give write access to anyone who >> *asks on our mailing lists* and has some connection to our projects. >> If that's what people mean by "open to all" I'm fine. > > Agreed IMO - It’s important for the triage activity to generate some type of notification email so that it is possible for the PMC to triage the triage. Regards, Dave > > Jacques > >> >> I suppose the .asf.yaml mechanism could be extended to list GitHub >> users who have this role? >> >> -Bertrand >> >> - >> 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
ASF events: inquiry on requirements for speakers
Dear Apache Development Community Team, I’ve checked your online resources and helpful tips with regards to upcoming ASF events. However, there are still a few questions which would be really helpful in order for us to prepare for listing us as potential speakers: * What are you looking for when deciding on the speakers? * Where can I find a full list of requirements for topics submission, format, etc.? * What is the timeline cycle for a speaker from the moment of applying to getting approved, presenting, etc.? * Who do we submit our proposal to? Is there anyone who I could perhaps call to get a bit more details? Thanks and I would highly appreciate your response! Thanks and best regards, Elena Elena Sporrer Engagement & Delivery Manager at datagrate C +1 (813) 970-7265 Tampa, FL Essential Enteprise Application Integration Solutions · Proud Partner since 2012
Re: Triage role on Github
Le 20/08/2020 à 15:08, Bertrand Delacretaz a écrit : On Thu, Aug 20, 2020 at 3:01 PM Harbs wrote: I also don’t see any harm in making triage rights open to all I suspect creative minds might find a way to spam us with this if it's "open to all" ? From my experience it always ends like this... For our wikis I think we generally give write access to anyone who *asks on our mailing lists* and has some connection to our projects. If that's what people mean by "open to all" I'm fine. Agreed Jacques I suppose the .asf.yaml mechanism could be extended to list GitHub users who have this role? -Bertrand - 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
Re: Triage role on Github
+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 wrote: > > > > On Aug 20, 2020, at 7:06 AM, Mark Thomas 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
Re: Triage role on Github
> On Aug 20, 2020, at 7:06 AM, Mark Thomas 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
Re: Triage role on Github
On Thu, Aug 20, 2020 at 3:01 PM Harbs wrote: > > I also don’t see any harm in making triage rights open to all I suspect creative minds might find a way to spam us with this if it's "open to all" ? For our wikis I think we generally give write access to anyone who *asks on our mailing lists* and has some connection to our projects. If that's what people mean by "open to all" I'm fine. I suppose the .asf.yaml mechanism could be extended to list GitHub users who have this role? -Bertrand - To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
Re: Triage role on Github
I also don’t see any harm in making triage rights open to all. There’s nothing destructive at all in the triage permissions, and it opens things up to a bit more frictionless contributions. Lowering the bar is good! :-) Harbs > On Aug 20, 2020, at 2:34 PM, Paul Angus wrote: > > I was thinking that we would/should/might follow the permissions philosophy > that we have for cwiki, but allowing anyone to be a Triager would make > administration of it a million times simpler. I would have not any objection > to it. > > > CTO > paul.an...@shapeblue.com > www.shapeblue.com > > > > > -Original Message- > From: Mark Thomas > Sent: 20 August 2020 12:07 > To: dev@community.apache.org > Subject: Re: Triage role on Github > > If you mean "grant the triage role to anyone with a GitHub account" then +1. > > 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-organization >> s-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
RE: Triage role on Github
I was thinking that we would/should/might follow the permissions philosophy that we have for cwiki, but allowing anyone to be a Triager would make administration of it a million times simpler. I would have not any objection to it. CTO paul.an...@shapeblue.com www.shapeblue.com -Original Message- From: Mark Thomas Sent: 20 August 2020 12:07 To: dev@community.apache.org Subject: Re: Triage role on Github If you mean "grant the triage role to anyone with a GitHub account" then +1. 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-organization > s-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
Re: Triage role on Github
If you mean "grant the triage role to anyone with a GitHub account" then +1. 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
Re: Triage role on Github
FYI similar discusion was raised on incubator list: https://lists.apache.org/thread.html/r497c5bf9a68e631bc93274e65beb3e28b769ce21e55961407adc5d10%40%3Cgeneral.incubator.apache.org%3E Cheers, Tomek On Thu, Aug 20, 2020 at 11:20 AM 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 >
Triage role on Github
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
