Re: Triage role on Github

[sebb]

On Sat, 22 Aug 2020 at 14:32, Rob Tompkins  wrote:
>
>
>
> > On Aug 20, 2020, at 9:34 AM, 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.
>
> 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

Re: Triage role on Github

[Rob Tompkins]

> On Aug 20, 2020, at 9:34 AM, 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.

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.

-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

Re: Triage role on Github

[Zhe Zhang]

Interesting feature. This feels to me similar to "branch committership"
(not sure about other projects but Hadoop uses it for major features). I
think it will help foster more engaged communities.

On Fri, Aug 21, 2020 at 1:45 AM 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 not have
> any objection to that...
>
>
> CTO
> paul.an...@shapeblue.com
> www.shapeblue.com
>
>
>
>
> -Original Message-
> From: Niclas Hedhman 
> Sent: 21 August 2020 07:32
> To: Apache Members 
> Cc: dev@community.apache.org
> Subject: Re: Triage role on Github
>
> This "elder" thinks this is all good, but you *could* rely more on social,
> rather than technical, solutions to achieve what you want without needing
> Infra assistance. If the concept is introduced in a given project, where
> people are given commit rights, with the explicit expectations only to use
> it for "triage" then I think it will be respected. Classic reference is
> Subversion project, which gives a social grant to a part of the codebase,
> although there is no technical means to prevent a committer to mess it up.
> But, if they do, it is easily restored and actions can be taken depending
> on the nature of the reason.
>
>
> // Niclas
>
> On Thu, Aug 20, 2020 at 5:20 PM 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
> >
> >
>

Re: Triage role on Github

[Maxime Beauchemin]

I started a similar thread in general@incubator
,
suggesting that we could use the newish ".asf.yaml"

as a place to manage the list of "triagers".

Personally, given the creativity of spammers and the rare but existing
flame wars in open source, I'm a bit worried of what could happen if we
open triage to all. Anyone with an API key could close / reopen all issues.
More anecdotally, random people with good intentions could misuse labels
(I'll make this issue a "top-priority", or label to be added in the next
release, move things around in the project view, delete wikis, or create
new labels that create more harm than good).

Also, given the fact that committers/PMC don't have repo admin rights, we
don't have direct access to protection mechanisms that GitHub offers, like
ghosting or banning users from repos.

Max

On 2020/08/20 21:22:21, Dave Fisher  wrote:
>
>
> > On Aug 20, 2020, at 12:48 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> 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
>
>

RE: Triage role on Github

[Paul Angus]

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 not have any objection to 
that...


CTO
paul.an...@shapeblue.com
www.shapeblue.com
 
 


-Original Message-
From: Niclas Hedhman  
Sent: 21 August 2020 07:32
To: Apache Members 
Cc: dev@community.apache.org
Subject: Re: Triage role on Github

This "elder" thinks this is all good, but you *could* rely more on social, 
rather than technical, solutions to achieve what you want without needing Infra 
assistance. If the concept is introduced in a given project, where people are 
given commit rights, with the explicit expectations only to use it for "triage" 
then I think it will be respected. Classic reference is Subversion project, 
which gives a social grant to a part of the codebase, although there is no 
technical means to prevent a committer to mess it up.
But, if they do, it is easily restored and actions can be taken depending on 
the nature of the reason.


// Niclas

On Thu, Aug 20, 2020 at 5:20 PM 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
>
>

Re: Triage role on Github

[Bertrand Delacretaz]

On Fri, Aug 21, 2020 at 8:32 AM Niclas Hedhman  wrote:
> ...If the concept is introduced in a given project, where people are given 
> commit
> rights, with the explicit expectations only to use it for "triage" then I 
> think it will
> be respected...


Great point, many projects do this with committers who are not
expected to touch the project's core without asking, for example, and
I think it works well.

+1 on making people committers so they can triage whatever's needed -
but of course it's each project's choice.

-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

[Niclas Hedhman]

This "elder" thinks this is all good, but you *could* rely more on social,
rather than technical, solutions to achieve what you want without needing
Infra assistance. If the concept is introduced in a given project, where
people are given commit rights, with the explicit expectations only to use
it for "triage" then I think it will be respected. Classic reference is
Subversion project, which gives a social grant to a part of the codebase,
although there is no technical means to prevent a committer to mess it up.
But, if they do, it is easily restored and actions can be taken depending
on the nature of the reason.


// Niclas

On Thu, Aug 20, 2020 at 5:20 PM 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
>
>

Re: Triage role on Github

[Dave Fisher]

> 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

Re: Triage role on Github

[Jacques Le Roux]

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

[Jarek Potiuk]

+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

[Rob Tompkins]

> 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

[Bertrand Delacretaz]

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

[Harbs]

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

[Paul Angus]

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

[Mark Thomas]

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

[Tomasz Urbaszek]

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
>