You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafodion.apache.org by Pierre Smits <pi...@gmail.com> on 2015/07/01 09:10:14 UTC
Re: Question on JIRA's
Assigning a JIRA ticket to someone else than yourself should only be done
with the explicit consent of the (potential) assignee. Please remember that
communication is the glue that holds a project (or podling) together and
happy. Doing a lot of work and then seeing it rejected (or reverted)
without the buy-in from the community can lead to that. Every contributor
always needs to keep in mind that, when it comes to code changes, consensus
is required. A single -1 (from a contributor with binding privileges) can
have the whole work reverted.
Especially with improvements (biggies, as opposed to smaller ones like
inproving a comment) should always go through a RTC process (review then
commit) in stead of CTR (commit then review) before stuff gets persisted
in code repositories.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Tue, Jun 30, 2015 at 11:58 PM, Birdsall, Dave <da...@hp.com>
wrote:
> I'm +1 at least for the set of privileges that Pierre mentions (
> https://cwiki.apache.org/confluence/display/INFRA/Role+Based+JIRA+Authorization
> ).
>
> The question of whether anyone should be able to assign a JIRA (perhaps
> restricted to themselves?) seems at root to be a question of how much
> control and when that committers wish to exercise. If anyone can assign to
> themselves, then they might do a lot of work and then get rejected when it
> is time to commit. If folks have to wait for a committer to assign
> something to them, they might get feedback earlier. On the other hand it
> would be a bottleneck that would tend to stop work rather than encouraging
> it.
>
> I'd like to hear more from Andrew about the specifics of how it is done in
> the HBase world.
>
> -----Original Message-----
> From: Subbiah, Suresh
> Sent: Saturday, June 27, 2015 1:56 PM
> To: dev@trafodion.incubator.apache.org
> Subject: RE: Question on JIRA's
>
> +1 For JIRA assignment privileges being granted to any registered JIRA
> User. With this model an interested contributor could create a JIRA and
> assign it to herself/himself if they feel it is appropriate.
> As I understand it this would extend JIRA assignment privileges beyond
> what is provided in the link given in Pierre's message below.
> Andrew did I understand correctly that for the HBase project the project
> administrator does "not" grant assignment priv on a case by case basis, but
> rather all registered JIRA users by default have JIRA assignment privs?
>
> Thank you
> Suresh
>
>
>
> -----Original Message-----
> From: Andrew Purtell [mailto:apurtell@apache.org]
> Sent: Friday, June 26, 2015 4:21 PM
> To: dev@trafodion.incubator.apache.org
> Subject: Re: Question on JIRA's
>
> Once the INFRA issue is sorted out the project administrator can grant
> assignment perms to any JIRA user. Many projects operate like this. We're
> doing this over on HBase now. +1 on assignment being a good contributor
> motivator, I believe this. At least, I'll admit it would work on me. It
> certainly doesn't hurt.
>
> On Fri, Jun 26, 2015 at 12:41 AM, Pierre Smits <pi...@gmail.com>
> wrote:
>
> > Roberta, All,
> >
> > Are you sure you want this project to have a methodology for
> > 'assigning' to other contributors? What I have learned over the years
> > within a few Apache projects is that when there is a restrictive
> > scheme for the greatest group of contributors (those without
> > privileges) involvement is of the lowest kind possible. Non-privileged
> > contributors just register issues (or don't at all), because they
> > don't feel ownership as they only have limited means to influence those
> with privileges.
> > Nothing hampers community growth more than restrictions on contributor
> > permissions. And within each Apache project there are already a
> > multitude of permissions schemes to consider and work with (from a
> > managerial point of view), as the underlying tools don't use an
> > integrated Authentication & Authorisation solution (e.g. JIRA vs
> Confluence).
> >
> > A solution to this predicament regarding JIRA issues could be the
> > following: in stead of opting where only contributors with privileges
> > (committers) have the permission to do issue assignment, let us opt
> > for the 'Default plus Contributor Assign Permission Scheme' as
> > described in
> >
> > https://cwiki.apache.org/confluence/display/INFRA/Role+Based+JIRA+Auth
> > orization
> > .
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *ORRTIZ.COM <http://www.orrtiz.com>*
> > Services & Solutions for Cloud-
> > Based Manufacturing, Professional
> > Services and Retail & Trade
> > http://www.orrtiz.com
> >
> > On Thu, Jun 25, 2015 at 7:09 PM, Marton, Roberta S
> > <ro...@hp.com>
> > wrote:
> >
> > > Thanks Alice. I knew this was needed to move over Lauchpad but
> > > missed
> > the
> > > assigning of JIRA bugs.
> > >
> > > Roberta
> > >
> > > -----Original Message-----
> > > From: Chen, Alice (Trafodion)
> > > Sent: Thursday, June 25, 2015 9:44 AM
> > > To: dev@trafodion.incubator.apache.org
> > > Subject: RE: Question on JIRA's
> > >
> > > Hello Roberta,
> > >
> > > We are blocked due to https://issues.apache.org/jira/browse/INFRA-9701
> .
> > > Our project was created but no administrator has been assigned nor
> > > has
> > our
> > > old LP bugs been imported yet.
> > >
> > > Cheers,
> > > Alice
> > >
> > > -----Original Message-----
> > > From: Marton, Roberta S
> > > Sent: Thursday, June 25, 2015 9:29 AM
> > > To: dev@trafodion.incubator.apache.org
> > > Subject: Question on JIRA's
> > >
> > > I have created my first JIRA this morning. A little confusion with
> > > the CREATE button but got that resolved.
> > >
> > > Looking at the current set of Trafodion JIRA's I see that they are
> > > all unassigned. I looked around a bit and could not figure out how
> > > to assign them.
> > > Perusing the internet, it looks like there is an administrator that
> > > can assign JIRA's.
> > > How should we be handling assigning Trafodion JIRAs? Can I just
> > > assign a JIRA to myself without any special privilege?
> > >
> > > And Pierre, great job in putting together the Trafodion wiki page.
> > >
> > > Roberta
> > >
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
Re: Question on JIRA's
Posted by Pierre Smits <pi...@gmail.com>.
Hi Selva,
I found the following (albeit somewhat dated), that may shed some light:
https://issues.apache.org/jira/browse/INFRA-2205
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Wed, Jul 1, 2015 at 7:14 PM, Selva Govindarajan <
selva.govindarajan@esgyn.com> wrote:
> Trafodion was using gerrit before it become a apache incubator project.
> Does github have a mechanism to vote for a commit as +2, +1 or -1.like
> gerrit had? If not, how should the reviewers communicate this to the
> committers.
>
>
> Selva
>
> On Wed, Jul 1, 2015 at 7:02 AM, Moran, Amanda <am...@hp.com>
> wrote:
>
> > Pierre-
> >
> > Thanks for the guidance. I know my group (we work on the installer) has
> > worked from the commit then review type of way so it's good to know this
> > information (since I would have continued to do it that way). Thanks
> again!
> >
> > Amanda
> >
> > Sent from my iPhone
> >
> > > On Jul 1, 2015, at 12:11 AM, "Pierre Smits" <pi...@gmail.com>
> > wrote:
> > >
> > > Assigning a JIRA ticket to someone else than yourself should only be
> done
> > > with the explicit consent of the (potential) assignee. Please remember
> > that
> > > communication is the glue that holds a project (or podling) together
> and
> > > happy. Doing a lot of work and then seeing it rejected (or reverted)
> > > without the buy-in from the community can lead to that. Every
> contributor
> > > always needs to keep in mind that, when it comes to code changes,
> > consensus
> > > is required. A single -1 (from a contributor with binding privileges)
> can
> > > have the whole work reverted.
> > >
> > > Especially with improvements (biggies, as opposed to smaller ones like
> > > inproving a comment) should always go through a RTC process (review
> then
> > > commit) in stead of CTR (commit then review) before stuff gets
> persisted
> > > in code repositories.
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > *ORRTIZ.COM <http://www.orrtiz.com>*
> > > Services & Solutions for Cloud-
> > > Based Manufacturing, Professional
> > > Services and Retail & Trade
> > > http://www.orrtiz.com
> > >
> > > On Tue, Jun 30, 2015 at 11:58 PM, Birdsall, Dave <dave.birdsall@hp.com
> >
> > > wrote:
> > >
> > >> I'm +1 at least for the set of privileges that Pierre mentions (
> > >>
> >
> https://cwiki.apache.org/confluence/display/INFRA/Role+Based+JIRA+Authorization
> > >> ).
> > >>
> > >> The question of whether anyone should be able to assign a JIRA
> (perhaps
> > >> restricted to themselves?) seems at root to be a question of how much
> > >> control and when that committers wish to exercise. If anyone can
> assign
> > to
> > >> themselves, then they might do a lot of work and then get rejected
> when
> > it
> > >> is time to commit. If folks have to wait for a committer to assign
> > >> something to them, they might get feedback earlier. On the other hand
> it
> > >> would be a bottleneck that would tend to stop work rather than
> > encouraging
> > >> it.
> > >>
> > >> I'd like to hear more from Andrew about the specifics of how it is
> done
> > in
> > >> the HBase world.
> > >>
> > >> -----Original Message-----
> > >> From: Subbiah, Suresh
> > >> Sent: Saturday, June 27, 2015 1:56 PM
> > >> To: dev@trafodion.incubator.apache.org
> > >> Subject: RE: Question on JIRA's
> > >>
> > >> +1 For JIRA assignment privileges being granted to any registered
> JIRA
> > >> User. With this model an interested contributor could create a JIRA
> and
> > >> assign it to herself/himself if they feel it is appropriate.
> > >> As I understand it this would extend JIRA assignment privileges beyond
> > >> what is provided in the link given in Pierre's message below.
> > >> Andrew did I understand correctly that for the HBase project the
> project
> > >> administrator does "not" grant assignment priv on a case by case
> basis,
> > but
> > >> rather all registered JIRA users by default have JIRA assignment
> privs?
> > >>
> > >> Thank you
> > >> Suresh
> > >>
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Andrew Purtell [mailto:apurtell@apache.org]
> > >> Sent: Friday, June 26, 2015 4:21 PM
> > >> To: dev@trafodion.incubator.apache.org
> > >> Subject: Re: Question on JIRA's
> > >>
> > >> Once the INFRA issue is sorted out the project administrator can grant
> > >> assignment perms to any JIRA user. Many projects operate like this.
> > We're
> > >> doing this over on HBase now. +1 on assignment being a good
> contributor
> > >> motivator, I believe this. At least, I'll admit it would work on me.
> It
> > >> certainly doesn't hurt.
> > >>
> > >> On Fri, Jun 26, 2015 at 12:41 AM, Pierre Smits <
> pierre.smits@gmail.com>
> > >> wrote:
> > >>
> > >>> Roberta, All,
> > >>>
> > >>> Are you sure you want this project to have a methodology for
> > >>> 'assigning' to other contributors? What I have learned over the years
> > >>> within a few Apache projects is that when there is a restrictive
> > >>> scheme for the greatest group of contributors (those without
> > >>> privileges) involvement is of the lowest kind possible.
> Non-privileged
> > >>> contributors just register issues (or don't at all), because they
> > >>> don't feel ownership as they only have limited means to influence
> those
> > >> with privileges.
> > >>> Nothing hampers community growth more than restrictions on
> contributor
> > >>> permissions. And within each Apache project there are already a
> > >>> multitude of permissions schemes to consider and work with (from a
> > >>> managerial point of view), as the underlying tools don't use an
> > >>> integrated Authentication & Authorisation solution (e.g. JIRA vs
> > >> Confluence).
> > >>>
> > >>> A solution to this predicament regarding JIRA issues could be the
> > >>> following: in stead of opting where only contributors with privileges
> > >>> (committers) have the permission to do issue assignment, let us opt
> > >>> for the 'Default plus Contributor Assign Permission Scheme' as
> > >>> described in
> > >>>
> > >>>
> https://cwiki.apache.org/confluence/display/INFRA/Role+Based+JIRA+Auth
> > >>> orization
> > >>> .
> > >>>
> > >>> Best regards,
> > >>>
> > >>> Pierre Smits
> > >>>
> > >>> *ORRTIZ.COM <http://www.orrtiz.com>*
> > >>> Services & Solutions for Cloud-
> > >>> Based Manufacturing, Professional
> > >>> Services and Retail & Trade
> > >>> http://www.orrtiz.com
> > >>>
> > >>> On Thu, Jun 25, 2015 at 7:09 PM, Marton, Roberta S
> > >>> <ro...@hp.com>
> > >>> wrote:
> > >>>
> > >>>> Thanks Alice. I knew this was needed to move over Lauchpad but
> > >>>> missed
> > >>> the
> > >>>> assigning of JIRA bugs.
> > >>>>
> > >>>> Roberta
> > >>>>
> > >>>> -----Original Message-----
> > >>>> From: Chen, Alice (Trafodion)
> > >>>> Sent: Thursday, June 25, 2015 9:44 AM
> > >>>> To: dev@trafodion.incubator.apache.org
> > >>>> Subject: RE: Question on JIRA's
> > >>>>
> > >>>> Hello Roberta,
> > >>>>
> > >>>> We are blocked due to
> > https://issues.apache.org/jira/browse/INFRA-9701
> > >> .
> > >>>> Our project was created but no administrator has been assigned nor
> > >>>> has
> > >>> our
> > >>>> old LP bugs been imported yet.
> > >>>>
> > >>>> Cheers,
> > >>>> Alice
> > >>>>
> > >>>> -----Original Message-----
> > >>>> From: Marton, Roberta S
> > >>>> Sent: Thursday, June 25, 2015 9:29 AM
> > >>>> To: dev@trafodion.incubator.apache.org
> > >>>> Subject: Question on JIRA's
> > >>>>
> > >>>> I have created my first JIRA this morning. A little confusion with
> > >>>> the CREATE button but got that resolved.
> > >>>>
> > >>>> Looking at the current set of Trafodion JIRA's I see that they are
> > >>>> all unassigned. I looked around a bit and could not figure out how
> > >>>> to assign them.
> > >>>> Perusing the internet, it looks like there is an administrator that
> > >>>> can assign JIRA's.
> > >>>> How should we be handling assigning Trafodion JIRAs? Can I just
> > >>>> assign a JIRA to myself without any special privilege?
> > >>>>
> > >>>> And Pierre, great job in putting together the Trafodion wiki page.
> > >>>>
> > >>>> Roberta
> > >>
> > >>
> > >>
> > >> --
> > >> Best regards,
> > >>
> > >> - Andy
> > >>
> > >> Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > >> (via Tom White)
> > >>
> >
>
Re: Question on JIRA's
Posted by Selva Govindarajan <se...@esgyn.com>.
Trafodion was using gerrit before it become a apache incubator project.
Does github have a mechanism to vote for a commit as +2, +1 or -1.like
gerrit had? If not, how should the reviewers communicate this to the
committers.
Selva
On Wed, Jul 1, 2015 at 7:02 AM, Moran, Amanda <am...@hp.com>
wrote:
> Pierre-
>
> Thanks for the guidance. I know my group (we work on the installer) has
> worked from the commit then review type of way so it's good to know this
> information (since I would have continued to do it that way). Thanks again!
>
> Amanda
>
> Sent from my iPhone
>
> > On Jul 1, 2015, at 12:11 AM, "Pierre Smits" <pi...@gmail.com>
> wrote:
> >
> > Assigning a JIRA ticket to someone else than yourself should only be done
> > with the explicit consent of the (potential) assignee. Please remember
> that
> > communication is the glue that holds a project (or podling) together and
> > happy. Doing a lot of work and then seeing it rejected (or reverted)
> > without the buy-in from the community can lead to that. Every contributor
> > always needs to keep in mind that, when it comes to code changes,
> consensus
> > is required. A single -1 (from a contributor with binding privileges) can
> > have the whole work reverted.
> >
> > Especially with improvements (biggies, as opposed to smaller ones like
> > inproving a comment) should always go through a RTC process (review then
> > commit) in stead of CTR (commit then review) before stuff gets persisted
> > in code repositories.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *ORRTIZ.COM <http://www.orrtiz.com>*
> > Services & Solutions for Cloud-
> > Based Manufacturing, Professional
> > Services and Retail & Trade
> > http://www.orrtiz.com
> >
> > On Tue, Jun 30, 2015 at 11:58 PM, Birdsall, Dave <da...@hp.com>
> > wrote:
> >
> >> I'm +1 at least for the set of privileges that Pierre mentions (
> >>
> https://cwiki.apache.org/confluence/display/INFRA/Role+Based+JIRA+Authorization
> >> ).
> >>
> >> The question of whether anyone should be able to assign a JIRA (perhaps
> >> restricted to themselves?) seems at root to be a question of how much
> >> control and when that committers wish to exercise. If anyone can assign
> to
> >> themselves, then they might do a lot of work and then get rejected when
> it
> >> is time to commit. If folks have to wait for a committer to assign
> >> something to them, they might get feedback earlier. On the other hand it
> >> would be a bottleneck that would tend to stop work rather than
> encouraging
> >> it.
> >>
> >> I'd like to hear more from Andrew about the specifics of how it is done
> in
> >> the HBase world.
> >>
> >> -----Original Message-----
> >> From: Subbiah, Suresh
> >> Sent: Saturday, June 27, 2015 1:56 PM
> >> To: dev@trafodion.incubator.apache.org
> >> Subject: RE: Question on JIRA's
> >>
> >> +1 For JIRA assignment privileges being granted to any registered JIRA
> >> User. With this model an interested contributor could create a JIRA and
> >> assign it to herself/himself if they feel it is appropriate.
> >> As I understand it this would extend JIRA assignment privileges beyond
> >> what is provided in the link given in Pierre's message below.
> >> Andrew did I understand correctly that for the HBase project the project
> >> administrator does "not" grant assignment priv on a case by case basis,
> but
> >> rather all registered JIRA users by default have JIRA assignment privs?
> >>
> >> Thank you
> >> Suresh
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Andrew Purtell [mailto:apurtell@apache.org]
> >> Sent: Friday, June 26, 2015 4:21 PM
> >> To: dev@trafodion.incubator.apache.org
> >> Subject: Re: Question on JIRA's
> >>
> >> Once the INFRA issue is sorted out the project administrator can grant
> >> assignment perms to any JIRA user. Many projects operate like this.
> We're
> >> doing this over on HBase now. +1 on assignment being a good contributor
> >> motivator, I believe this. At least, I'll admit it would work on me. It
> >> certainly doesn't hurt.
> >>
> >> On Fri, Jun 26, 2015 at 12:41 AM, Pierre Smits <pi...@gmail.com>
> >> wrote:
> >>
> >>> Roberta, All,
> >>>
> >>> Are you sure you want this project to have a methodology for
> >>> 'assigning' to other contributors? What I have learned over the years
> >>> within a few Apache projects is that when there is a restrictive
> >>> scheme for the greatest group of contributors (those without
> >>> privileges) involvement is of the lowest kind possible. Non-privileged
> >>> contributors just register issues (or don't at all), because they
> >>> don't feel ownership as they only have limited means to influence those
> >> with privileges.
> >>> Nothing hampers community growth more than restrictions on contributor
> >>> permissions. And within each Apache project there are already a
> >>> multitude of permissions schemes to consider and work with (from a
> >>> managerial point of view), as the underlying tools don't use an
> >>> integrated Authentication & Authorisation solution (e.g. JIRA vs
> >> Confluence).
> >>>
> >>> A solution to this predicament regarding JIRA issues could be the
> >>> following: in stead of opting where only contributors with privileges
> >>> (committers) have the permission to do issue assignment, let us opt
> >>> for the 'Default plus Contributor Assign Permission Scheme' as
> >>> described in
> >>>
> >>> https://cwiki.apache.org/confluence/display/INFRA/Role+Based+JIRA+Auth
> >>> orization
> >>> .
> >>>
> >>> Best regards,
> >>>
> >>> Pierre Smits
> >>>
> >>> *ORRTIZ.COM <http://www.orrtiz.com>*
> >>> Services & Solutions for Cloud-
> >>> Based Manufacturing, Professional
> >>> Services and Retail & Trade
> >>> http://www.orrtiz.com
> >>>
> >>> On Thu, Jun 25, 2015 at 7:09 PM, Marton, Roberta S
> >>> <ro...@hp.com>
> >>> wrote:
> >>>
> >>>> Thanks Alice. I knew this was needed to move over Lauchpad but
> >>>> missed
> >>> the
> >>>> assigning of JIRA bugs.
> >>>>
> >>>> Roberta
> >>>>
> >>>> -----Original Message-----
> >>>> From: Chen, Alice (Trafodion)
> >>>> Sent: Thursday, June 25, 2015 9:44 AM
> >>>> To: dev@trafodion.incubator.apache.org
> >>>> Subject: RE: Question on JIRA's
> >>>>
> >>>> Hello Roberta,
> >>>>
> >>>> We are blocked due to
> https://issues.apache.org/jira/browse/INFRA-9701
> >> .
> >>>> Our project was created but no administrator has been assigned nor
> >>>> has
> >>> our
> >>>> old LP bugs been imported yet.
> >>>>
> >>>> Cheers,
> >>>> Alice
> >>>>
> >>>> -----Original Message-----
> >>>> From: Marton, Roberta S
> >>>> Sent: Thursday, June 25, 2015 9:29 AM
> >>>> To: dev@trafodion.incubator.apache.org
> >>>> Subject: Question on JIRA's
> >>>>
> >>>> I have created my first JIRA this morning. A little confusion with
> >>>> the CREATE button but got that resolved.
> >>>>
> >>>> Looking at the current set of Trafodion JIRA's I see that they are
> >>>> all unassigned. I looked around a bit and could not figure out how
> >>>> to assign them.
> >>>> Perusing the internet, it looks like there is an administrator that
> >>>> can assign JIRA's.
> >>>> How should we be handling assigning Trafodion JIRAs? Can I just
> >>>> assign a JIRA to myself without any special privilege?
> >>>>
> >>>> And Pierre, great job in putting together the Trafodion wiki page.
> >>>>
> >>>> Roberta
> >>
> >>
> >>
> >> --
> >> Best regards,
> >>
> >> - Andy
> >>
> >> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> >> (via Tom White)
> >>
>
Re: Question on JIRA's
Posted by "Moran, Amanda" <am...@hp.com>.
Pierre-
Thanks for the guidance. I know my group (we work on the installer) has worked from the commit then review type of way so it's good to know this information (since I would have continued to do it that way). Thanks again!
Amanda
Sent from my iPhone
> On Jul 1, 2015, at 12:11 AM, "Pierre Smits" <pi...@gmail.com> wrote:
>
> Assigning a JIRA ticket to someone else than yourself should only be done
> with the explicit consent of the (potential) assignee. Please remember that
> communication is the glue that holds a project (or podling) together and
> happy. Doing a lot of work and then seeing it rejected (or reverted)
> without the buy-in from the community can lead to that. Every contributor
> always needs to keep in mind that, when it comes to code changes, consensus
> is required. A single -1 (from a contributor with binding privileges) can
> have the whole work reverted.
>
> Especially with improvements (biggies, as opposed to smaller ones like
> inproving a comment) should always go through a RTC process (review then
> commit) in stead of CTR (commit then review) before stuff gets persisted
> in code repositories.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Tue, Jun 30, 2015 at 11:58 PM, Birdsall, Dave <da...@hp.com>
> wrote:
>
>> I'm +1 at least for the set of privileges that Pierre mentions (
>> https://cwiki.apache.org/confluence/display/INFRA/Role+Based+JIRA+Authorization
>> ).
>>
>> The question of whether anyone should be able to assign a JIRA (perhaps
>> restricted to themselves?) seems at root to be a question of how much
>> control and when that committers wish to exercise. If anyone can assign to
>> themselves, then they might do a lot of work and then get rejected when it
>> is time to commit. If folks have to wait for a committer to assign
>> something to them, they might get feedback earlier. On the other hand it
>> would be a bottleneck that would tend to stop work rather than encouraging
>> it.
>>
>> I'd like to hear more from Andrew about the specifics of how it is done in
>> the HBase world.
>>
>> -----Original Message-----
>> From: Subbiah, Suresh
>> Sent: Saturday, June 27, 2015 1:56 PM
>> To: dev@trafodion.incubator.apache.org
>> Subject: RE: Question on JIRA's
>>
>> +1 For JIRA assignment privileges being granted to any registered JIRA
>> User. With this model an interested contributor could create a JIRA and
>> assign it to herself/himself if they feel it is appropriate.
>> As I understand it this would extend JIRA assignment privileges beyond
>> what is provided in the link given in Pierre's message below.
>> Andrew did I understand correctly that for the HBase project the project
>> administrator does "not" grant assignment priv on a case by case basis, but
>> rather all registered JIRA users by default have JIRA assignment privs?
>>
>> Thank you
>> Suresh
>>
>>
>>
>> -----Original Message-----
>> From: Andrew Purtell [mailto:apurtell@apache.org]
>> Sent: Friday, June 26, 2015 4:21 PM
>> To: dev@trafodion.incubator.apache.org
>> Subject: Re: Question on JIRA's
>>
>> Once the INFRA issue is sorted out the project administrator can grant
>> assignment perms to any JIRA user. Many projects operate like this. We're
>> doing this over on HBase now. +1 on assignment being a good contributor
>> motivator, I believe this. At least, I'll admit it would work on me. It
>> certainly doesn't hurt.
>>
>> On Fri, Jun 26, 2015 at 12:41 AM, Pierre Smits <pi...@gmail.com>
>> wrote:
>>
>>> Roberta, All,
>>>
>>> Are you sure you want this project to have a methodology for
>>> 'assigning' to other contributors? What I have learned over the years
>>> within a few Apache projects is that when there is a restrictive
>>> scheme for the greatest group of contributors (those without
>>> privileges) involvement is of the lowest kind possible. Non-privileged
>>> contributors just register issues (or don't at all), because they
>>> don't feel ownership as they only have limited means to influence those
>> with privileges.
>>> Nothing hampers community growth more than restrictions on contributor
>>> permissions. And within each Apache project there are already a
>>> multitude of permissions schemes to consider and work with (from a
>>> managerial point of view), as the underlying tools don't use an
>>> integrated Authentication & Authorisation solution (e.g. JIRA vs
>> Confluence).
>>>
>>> A solution to this predicament regarding JIRA issues could be the
>>> following: in stead of opting where only contributors with privileges
>>> (committers) have the permission to do issue assignment, let us opt
>>> for the 'Default plus Contributor Assign Permission Scheme' as
>>> described in
>>>
>>> https://cwiki.apache.org/confluence/display/INFRA/Role+Based+JIRA+Auth
>>> orization
>>> .
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Thu, Jun 25, 2015 at 7:09 PM, Marton, Roberta S
>>> <ro...@hp.com>
>>> wrote:
>>>
>>>> Thanks Alice. I knew this was needed to move over Lauchpad but
>>>> missed
>>> the
>>>> assigning of JIRA bugs.
>>>>
>>>> Roberta
>>>>
>>>> -----Original Message-----
>>>> From: Chen, Alice (Trafodion)
>>>> Sent: Thursday, June 25, 2015 9:44 AM
>>>> To: dev@trafodion.incubator.apache.org
>>>> Subject: RE: Question on JIRA's
>>>>
>>>> Hello Roberta,
>>>>
>>>> We are blocked due to https://issues.apache.org/jira/browse/INFRA-9701
>> .
>>>> Our project was created but no administrator has been assigned nor
>>>> has
>>> our
>>>> old LP bugs been imported yet.
>>>>
>>>> Cheers,
>>>> Alice
>>>>
>>>> -----Original Message-----
>>>> From: Marton, Roberta S
>>>> Sent: Thursday, June 25, 2015 9:29 AM
>>>> To: dev@trafodion.incubator.apache.org
>>>> Subject: Question on JIRA's
>>>>
>>>> I have created my first JIRA this morning. A little confusion with
>>>> the CREATE button but got that resolved.
>>>>
>>>> Looking at the current set of Trafodion JIRA's I see that they are
>>>> all unassigned. I looked around a bit and could not figure out how
>>>> to assign them.
>>>> Perusing the internet, it looks like there is an administrator that
>>>> can assign JIRA's.
>>>> How should we be handling assigning Trafodion JIRAs? Can I just
>>>> assign a JIRA to myself without any special privilege?
>>>>
>>>> And Pierre, great job in putting together the Trafodion wiki page.
>>>>
>>>> Roberta
>>
>>
>>
>> --
>> Best regards,
>>
>> - Andy
>>
>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> (via Tom White)
>>
Re: Question on JIRA's
Posted by Andrew Purtell <ap...@apache.org>.
+1, it's a good idea not to reassign a JIRA without consent of the current
assignee, or if the current assignee doesn't respond to an inquiry on the
JIRA after a reasonable amount of time. Helps prevent misunderstandings and
hurt feelings.
On Wed, Jul 1, 2015 at 12:10 AM, Pierre Smits <pi...@gmail.com>
wrote:
> Assigning a JIRA ticket to someone else than yourself should only be done
> with the explicit consent of the (potential) assignee. Please remember that
> communication is the glue that holds a project (or podling) together and
> happy. Doing a lot of work and then seeing it rejected (or reverted)
> without the buy-in from the community can lead to that. Every contributor
> always needs to keep in mind that, when it comes to code changes, consensus
> is required. A single -1 (from a contributor with binding privileges) can
> have the whole work reverted.
>
> Especially with improvements (biggies, as opposed to smaller ones like
> inproving a comment) should always go through a RTC process (review then
> commit) in stead of CTR (commit then review) before stuff gets persisted
> in code repositories.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Tue, Jun 30, 2015 at 11:58 PM, Birdsall, Dave <da...@hp.com>
> wrote:
>
> > I'm +1 at least for the set of privileges that Pierre mentions (
> >
> https://cwiki.apache.org/confluence/display/INFRA/Role+Based+JIRA+Authorization
> > ).
> >
> > The question of whether anyone should be able to assign a JIRA (perhaps
> > restricted to themselves?) seems at root to be a question of how much
> > control and when that committers wish to exercise. If anyone can assign
> to
> > themselves, then they might do a lot of work and then get rejected when
> it
> > is time to commit. If folks have to wait for a committer to assign
> > something to them, they might get feedback earlier. On the other hand it
> > would be a bottleneck that would tend to stop work rather than
> encouraging
> > it.
> >
> > I'd like to hear more from Andrew about the specifics of how it is done
> in
> > the HBase world.
> >
> > -----Original Message-----
> > From: Subbiah, Suresh
> > Sent: Saturday, June 27, 2015 1:56 PM
> > To: dev@trafodion.incubator.apache.org
> > Subject: RE: Question on JIRA's
> >
> > +1 For JIRA assignment privileges being granted to any registered JIRA
> > User. With this model an interested contributor could create a JIRA and
> > assign it to herself/himself if they feel it is appropriate.
> > As I understand it this would extend JIRA assignment privileges beyond
> > what is provided in the link given in Pierre's message below.
> > Andrew did I understand correctly that for the HBase project the project
> > administrator does "not" grant assignment priv on a case by case basis,
> but
> > rather all registered JIRA users by default have JIRA assignment privs?
> >
> > Thank you
> > Suresh
> >
> >
> >
> > -----Original Message-----
> > From: Andrew Purtell [mailto:apurtell@apache.org]
> > Sent: Friday, June 26, 2015 4:21 PM
> > To: dev@trafodion.incubator.apache.org
> > Subject: Re: Question on JIRA's
> >
> > Once the INFRA issue is sorted out the project administrator can grant
> > assignment perms to any JIRA user. Many projects operate like this. We're
> > doing this over on HBase now. +1 on assignment being a good contributor
> > motivator, I believe this. At least, I'll admit it would work on me. It
> > certainly doesn't hurt.
> >
> > On Fri, Jun 26, 2015 at 12:41 AM, Pierre Smits <pi...@gmail.com>
> > wrote:
> >
> > > Roberta, All,
> > >
> > > Are you sure you want this project to have a methodology for
> > > 'assigning' to other contributors? What I have learned over the years
> > > within a few Apache projects is that when there is a restrictive
> > > scheme for the greatest group of contributors (those without
> > > privileges) involvement is of the lowest kind possible. Non-privileged
> > > contributors just register issues (or don't at all), because they
> > > don't feel ownership as they only have limited means to influence those
> > with privileges.
> > > Nothing hampers community growth more than restrictions on contributor
> > > permissions. And within each Apache project there are already a
> > > multitude of permissions schemes to consider and work with (from a
> > > managerial point of view), as the underlying tools don't use an
> > > integrated Authentication & Authorisation solution (e.g. JIRA vs
> > Confluence).
> > >
> > > A solution to this predicament regarding JIRA issues could be the
> > > following: in stead of opting where only contributors with privileges
> > > (committers) have the permission to do issue assignment, let us opt
> > > for the 'Default plus Contributor Assign Permission Scheme' as
> > > described in
> > >
> > > https://cwiki.apache.org/confluence/display/INFRA/Role+Based+JIRA+Auth
> > > orization
> > > .
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > *ORRTIZ.COM <http://www.orrtiz.com>*
> > > Services & Solutions for Cloud-
> > > Based Manufacturing, Professional
> > > Services and Retail & Trade
> > > http://www.orrtiz.com
> > >
> > > On Thu, Jun 25, 2015 at 7:09 PM, Marton, Roberta S
> > > <ro...@hp.com>
> > > wrote:
> > >
> > > > Thanks Alice. I knew this was needed to move over Lauchpad but
> > > > missed
> > > the
> > > > assigning of JIRA bugs.
> > > >
> > > > Roberta
> > > >
> > > > -----Original Message-----
> > > > From: Chen, Alice (Trafodion)
> > > > Sent: Thursday, June 25, 2015 9:44 AM
> > > > To: dev@trafodion.incubator.apache.org
> > > > Subject: RE: Question on JIRA's
> > > >
> > > > Hello Roberta,
> > > >
> > > > We are blocked due to
> https://issues.apache.org/jira/browse/INFRA-9701
> > .
> > > > Our project was created but no administrator has been assigned nor
> > > > has
> > > our
> > > > old LP bugs been imported yet.
> > > >
> > > > Cheers,
> > > > Alice
> > > >
> > > > -----Original Message-----
> > > > From: Marton, Roberta S
> > > > Sent: Thursday, June 25, 2015 9:29 AM
> > > > To: dev@trafodion.incubator.apache.org
> > > > Subject: Question on JIRA's
> > > >
> > > > I have created my first JIRA this morning. A little confusion with
> > > > the CREATE button but got that resolved.
> > > >
> > > > Looking at the current set of Trafodion JIRA's I see that they are
> > > > all unassigned. I looked around a bit and could not figure out how
> > > > to assign them.
> > > > Perusing the internet, it looks like there is an administrator that
> > > > can assign JIRA's.
> > > > How should we be handling assigning Trafodion JIRAs? Can I just
> > > > assign a JIRA to myself without any special privilege?
> > > >
> > > > And Pierre, great job in putting together the Trafodion wiki page.
> > > >
> > > > Roberta
> > > >
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)