You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Lorin Beer <lo...@gmail.com> on 2013/06/04 23:17:00 UTC
Cordova vs Company workflow
I've CC'd the relevant parties, but as a reminder of best practice:
regardless of internal company workflow for Cordova contribution, when
tackling an issue filed on jira:
1. if it is not assigned to you, ping the person it is assigned to
2. discuss assigning to yourself
3. begin solving the issue
Keeping work in non-apache repos, and chiming in with a fix once the
issue has already been resolved leads to frustration and duplication
of work.
Clear communication is key to cooperating on a project like this, and
that involves letting everyone know what you are working on. The
system we employ for that purpose is JIRA.
- Lorin
Re: Cordova vs Company workflow
Posted by Carlos Santana <cs...@gmail.com>.
Since I'm starting as a contributor and not a committer I was talking from
that perpective, to follow the process that is in place for contributors to
submit pull requests to be review and committed by committers.
--Carlos
On Wed, Jun 5, 2013 at 8:28 PM, Jesse <pu...@gmail.com> wrote:
> Personally, if I had a change that I wanted to add to Android, or iOS, I
> would send a pull request to Joe, or Shazron respectively. I effectively
> consider them to be the gatekeepers for their respective platforms as they
> work on them every day and I consider them to have a much deeper knowledge
> of implications that I might not have thought of. This inevitably leads to
> a brief discussion, ... Why did you make this change? How confident are you
> that this doesn't break shit? Did you test it? All of which are
> important, but perhaps more important is the resultant communication.
>
> Myself, I do ALL my work in my github fork and maintain multiple branches
> there, and I LOVE it when I get a pull request for WP7, WP8, or Windows8,
> which are the platforms I look after day to day.
>
>
>
> @purplecabbage
> risingj.com
>
>
> On Wed, Jun 5, 2013 at 4:36 PM, Joe Bowser <bo...@gmail.com> wrote:
>
> > The thing is that people don't start out as committers. It has to be
> earned
> > over time. Committership is with an individual, not a company.
> > On Jun 5, 2013 4:32 PM, "Filip Maj" <fi...@adobe.com> wrote:
> >
> > > Agree with Lorin, if you are a committer, go ahead and push your
> changes
> > > but please for the love of god test every change you make. If you
> cannot
> > > test due to lack of devices, then please for the love of god ask
> someone
> > > on the list to do the testing for you.
> > >
> > > On 6/5/13 4:30 PM, "Lorin Beer" <lo...@gmail.com> wrote:
> > >
> > > >-1 for allowing time for discussion/code-review between
> diff/commit/pull
> > > >request to the issue and committing to master, if I understand the
> > > >suggestion.
> > > >
> > > >For non-committer contributors, yes, this is a natural workflow and
> > > >a necessary step for getting your code into the project in the first
> > > >place.
> > > >
> > > >But the status of committership denotes those that are trusted to push
> > > >commits to master without the contribution being vetted by someone
> else.
> > > >If
> > > >the commit adds additional functionality or drastically changes
> existing
> > > >functionality, the workflow is to discuss it on the list and open up a
> > > >lazy
> > > >consensus vote *prior* to beginning work on it in the first place.
> > > >
> > > >
> > > >
> > > >On Wed, Jun 5, 2013 at 11:44 AM, Carlos Santana
> > > ><cs...@gmail.com>wrote:
> > > >
> > > >> +1 on moving to Status:"In Progress" to denote someone is working on
> > it
> > > >> +1 on allowing time for discussion/code-review between request and
> > > >>commit
> > > >>
> > > >> Sorry trying to learn the Cordova lingo :-)
> > > >>
> > > >> --Carlos
> > > >>
> > > >>
> > > >> On Wed, Jun 5, 2013 at 2:32 PM, Jeffrey Heifetz <
> > > jheifetz@blackberry.com
> > > >> >wrote:
> > > >>
> > > >> > I also think there's value in having some time between posting a
> > > >> > diff/commit/pull request to the issue and committing to master to
> > > >>allow
> > > >> > some discussion.
> > > >> >
> > > >> > On 13-06-05 2:25 PM, "Lorin Beer" <lo...@gmail.com>
> wrote:
> > > >> >
> > > >> > >Yes, putting a comment on the issue itself should be sufficient.
> If
> > > >> > >you're familiar with the person, im/irc message is appreciated,
> but
> > > >> > >not necessary.
> > > >> > >
> > > >> > >Generally, Fil is correct. I generally do not mark issues I'm
> > working
> > > >> > >on as "in progress", but that's something I will immediately
> > adress.
> > > >> > >
> > > >> > >On Wed, Jun 5, 2013 at 9:41 AM, Filip Maj <fi...@adobe.com> wrote:
> > > >> > >> Pretty much.
> > > >> > >>
> > > >> > >> My assumption is when looking through JIRA that if an issue
> isn't
> > > >>"In
> > > >> > >> Progress" then I can freely assign to myself and mark it as "In
> > > >> > >>Progress"
> > > >> > >> to denote that I am working on it.
> > > >> > >>
> > > >> > >> On 6/5/13 9:28 AM, "Carlos Santana" <cs...@gmail.com>
> > wrote:
> > > >> > >>
> > > >> > >>>Lorin,
> > > >> > >>> When you say "ping the person it is assigned to" you mean
> put a
> > > >> > >>>comment
> > > >> > >>>on the JIRA ticket?
> > > >> > >>>This way everyone is aware that someone is interested on taking
> > > >>over
> > > >> the
> > > >> > >>>ticket or have some input?
> > > >> > >>>
> > > >> > >>>Sorry if it was a dumb, question I'm trying to understand the
> > > >>workflow
> > > >> > >>>of
> > > >> > >>>contributing
> > > >> > >>>
> > > >> > >>>(open ticket, add comment to JIRA ticket showing interest on
> > > >>working
> > > >> the
> > > >> > >>>ticket, get agreement from assignee, start solving problem,
> > submit
> > > >> pull
> > > >> > >>>request, post to dev mailing list for code review)
> > > >> > >>>
> > > >> > >>>
> > > >> > >>>--Carlos
> > > >> > >>>
> > > >> > >>>
> > > >> > >>>On Tue, Jun 4, 2013 at 5:17 PM, Lorin Beer
> > > >><lo...@gmail.com>
> > > >> > >>>wrote:
> > > >> > >>>
> > > >> > >>>> I've CC'd the relevant parties, but as a reminder of best
> > > >>practice:
> > > >> > >>>>
> > > >> > >>>> regardless of internal company workflow for Cordova
> > contribution,
> > > >> when
> > > >> > >>>> tackling an issue filed on jira:
> > > >> > >>>>
> > > >> > >>>> 1. if it is not assigned to you, ping the person it is
> assigned
> > > >>to
> > > >> > >>>> 2. discuss assigning to yourself
> > > >> > >>>> 3. begin solving the issue
> > > >> > >>>>
> > > >> > >>>> Keeping work in non-apache repos, and chiming in with a fix
> > once
> > > >>the
> > > >> > >>>> issue has already been resolved leads to frustration and
> > > >>duplication
> > > >> > >>>> of work.
> > > >> > >>>>
> > > >> > >>>> Clear communication is key to cooperating on a project like
> > this,
> > > >> and
> > > >> > >>>> that involves letting everyone know what you are working on.
> > The
> > > >> > >>>> system we employ for that purpose is JIRA.
> > > >> > >>>>
> > > >> > >>>> - Lorin
> > > >> > >>>>
> > > >> > >>>
> > > >> > >>>
> > > >> > >>>
> > > >> > >>>--
> > > >> > >>>Carlos Santana
> > > >> > >>><cs...@gmail.com>
> > > >> > >>
> > > >> >
> > > >> >
> > > >> >
> > ---------------------------------------------------------------------
> > > >> > This transmission (including any attachments) may contain
> > confidential
> > > >> > information, privileged material (including material protected by
> > the
> > > >> > solicitor-client or other applicable privileges), or constitute
> > > >> non-public
> > > >> > information. Any use of this information by anyone other than the
> > > >> intended
> > > >> > recipient is prohibited. If you have received this transmission in
> > > >>error,
> > > >> > please immediately reply to the sender and delete this information
> > > >>from
> > > >> > your system. Use, dissemination, distribution, or reproduction of
> > this
> > > >> > transmission by unintended recipients is not authorized and may be
> > > >> unlawful.
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Carlos Santana
> > > >> <cs...@gmail.com>
> > > >>
> > >
> > >
> >
>
--
Carlos Santana
<cs...@gmail.com>
Re: Cordova vs Company workflow
Posted by Jesse <pu...@gmail.com>.
Personally, if I had a change that I wanted to add to Android, or iOS, I
would send a pull request to Joe, or Shazron respectively. I effectively
consider them to be the gatekeepers for their respective platforms as they
work on them every day and I consider them to have a much deeper knowledge
of implications that I might not have thought of. This inevitably leads to
a brief discussion, ... Why did you make this change? How confident are you
that this doesn't break shit? Did you test it? All of which are
important, but perhaps more important is the resultant communication.
Myself, I do ALL my work in my github fork and maintain multiple branches
there, and I LOVE it when I get a pull request for WP7, WP8, or Windows8,
which are the platforms I look after day to day.
@purplecabbage
risingj.com
On Wed, Jun 5, 2013 at 4:36 PM, Joe Bowser <bo...@gmail.com> wrote:
> The thing is that people don't start out as committers. It has to be earned
> over time. Committership is with an individual, not a company.
> On Jun 5, 2013 4:32 PM, "Filip Maj" <fi...@adobe.com> wrote:
>
> > Agree with Lorin, if you are a committer, go ahead and push your changes
> > but please for the love of god test every change you make. If you cannot
> > test due to lack of devices, then please for the love of god ask someone
> > on the list to do the testing for you.
> >
> > On 6/5/13 4:30 PM, "Lorin Beer" <lo...@gmail.com> wrote:
> >
> > >-1 for allowing time for discussion/code-review between diff/commit/pull
> > >request to the issue and committing to master, if I understand the
> > >suggestion.
> > >
> > >For non-committer contributors, yes, this is a natural workflow and
> > >a necessary step for getting your code into the project in the first
> > >place.
> > >
> > >But the status of committership denotes those that are trusted to push
> > >commits to master without the contribution being vetted by someone else.
> > >If
> > >the commit adds additional functionality or drastically changes existing
> > >functionality, the workflow is to discuss it on the list and open up a
> > >lazy
> > >consensus vote *prior* to beginning work on it in the first place.
> > >
> > >
> > >
> > >On Wed, Jun 5, 2013 at 11:44 AM, Carlos Santana
> > ><cs...@gmail.com>wrote:
> > >
> > >> +1 on moving to Status:"In Progress" to denote someone is working on
> it
> > >> +1 on allowing time for discussion/code-review between request and
> > >>commit
> > >>
> > >> Sorry trying to learn the Cordova lingo :-)
> > >>
> > >> --Carlos
> > >>
> > >>
> > >> On Wed, Jun 5, 2013 at 2:32 PM, Jeffrey Heifetz <
> > jheifetz@blackberry.com
> > >> >wrote:
> > >>
> > >> > I also think there's value in having some time between posting a
> > >> > diff/commit/pull request to the issue and committing to master to
> > >>allow
> > >> > some discussion.
> > >> >
> > >> > On 13-06-05 2:25 PM, "Lorin Beer" <lo...@gmail.com> wrote:
> > >> >
> > >> > >Yes, putting a comment on the issue itself should be sufficient. If
> > >> > >you're familiar with the person, im/irc message is appreciated, but
> > >> > >not necessary.
> > >> > >
> > >> > >Generally, Fil is correct. I generally do not mark issues I'm
> working
> > >> > >on as "in progress", but that's something I will immediately
> adress.
> > >> > >
> > >> > >On Wed, Jun 5, 2013 at 9:41 AM, Filip Maj <fi...@adobe.com> wrote:
> > >> > >> Pretty much.
> > >> > >>
> > >> > >> My assumption is when looking through JIRA that if an issue isn't
> > >>"In
> > >> > >> Progress" then I can freely assign to myself and mark it as "In
> > >> > >>Progress"
> > >> > >> to denote that I am working on it.
> > >> > >>
> > >> > >> On 6/5/13 9:28 AM, "Carlos Santana" <cs...@gmail.com>
> wrote:
> > >> > >>
> > >> > >>>Lorin,
> > >> > >>> When you say "ping the person it is assigned to" you mean put a
> > >> > >>>comment
> > >> > >>>on the JIRA ticket?
> > >> > >>>This way everyone is aware that someone is interested on taking
> > >>over
> > >> the
> > >> > >>>ticket or have some input?
> > >> > >>>
> > >> > >>>Sorry if it was a dumb, question I'm trying to understand the
> > >>workflow
> > >> > >>>of
> > >> > >>>contributing
> > >> > >>>
> > >> > >>>(open ticket, add comment to JIRA ticket showing interest on
> > >>working
> > >> the
> > >> > >>>ticket, get agreement from assignee, start solving problem,
> submit
> > >> pull
> > >> > >>>request, post to dev mailing list for code review)
> > >> > >>>
> > >> > >>>
> > >> > >>>--Carlos
> > >> > >>>
> > >> > >>>
> > >> > >>>On Tue, Jun 4, 2013 at 5:17 PM, Lorin Beer
> > >><lo...@gmail.com>
> > >> > >>>wrote:
> > >> > >>>
> > >> > >>>> I've CC'd the relevant parties, but as a reminder of best
> > >>practice:
> > >> > >>>>
> > >> > >>>> regardless of internal company workflow for Cordova
> contribution,
> > >> when
> > >> > >>>> tackling an issue filed on jira:
> > >> > >>>>
> > >> > >>>> 1. if it is not assigned to you, ping the person it is assigned
> > >>to
> > >> > >>>> 2. discuss assigning to yourself
> > >> > >>>> 3. begin solving the issue
> > >> > >>>>
> > >> > >>>> Keeping work in non-apache repos, and chiming in with a fix
> once
> > >>the
> > >> > >>>> issue has already been resolved leads to frustration and
> > >>duplication
> > >> > >>>> of work.
> > >> > >>>>
> > >> > >>>> Clear communication is key to cooperating on a project like
> this,
> > >> and
> > >> > >>>> that involves letting everyone know what you are working on.
> The
> > >> > >>>> system we employ for that purpose is JIRA.
> > >> > >>>>
> > >> > >>>> - Lorin
> > >> > >>>>
> > >> > >>>
> > >> > >>>
> > >> > >>>
> > >> > >>>--
> > >> > >>>Carlos Santana
> > >> > >>><cs...@gmail.com>
> > >> > >>
> > >> >
> > >> >
> > >> >
> ---------------------------------------------------------------------
> > >> > This transmission (including any attachments) may contain
> confidential
> > >> > information, privileged material (including material protected by
> the
> > >> > solicitor-client or other applicable privileges), or constitute
> > >> non-public
> > >> > information. Any use of this information by anyone other than the
> > >> intended
> > >> > recipient is prohibited. If you have received this transmission in
> > >>error,
> > >> > please immediately reply to the sender and delete this information
> > >>from
> > >> > your system. Use, dissemination, distribution, or reproduction of
> this
> > >> > transmission by unintended recipients is not authorized and may be
> > >> unlawful.
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Carlos Santana
> > >> <cs...@gmail.com>
> > >>
> >
> >
>
Re: Cordova vs Company workflow
Posted by Joe Bowser <bo...@gmail.com>.
The thing is that people don't start out as committers. It has to be earned
over time. Committership is with an individual, not a company.
On Jun 5, 2013 4:32 PM, "Filip Maj" <fi...@adobe.com> wrote:
> Agree with Lorin, if you are a committer, go ahead and push your changes
> but please for the love of god test every change you make. If you cannot
> test due to lack of devices, then please for the love of god ask someone
> on the list to do the testing for you.
>
> On 6/5/13 4:30 PM, "Lorin Beer" <lo...@gmail.com> wrote:
>
> >-1 for allowing time for discussion/code-review between diff/commit/pull
> >request to the issue and committing to master, if I understand the
> >suggestion.
> >
> >For non-committer contributors, yes, this is a natural workflow and
> >a necessary step for getting your code into the project in the first
> >place.
> >
> >But the status of committership denotes those that are trusted to push
> >commits to master without the contribution being vetted by someone else.
> >If
> >the commit adds additional functionality or drastically changes existing
> >functionality, the workflow is to discuss it on the list and open up a
> >lazy
> >consensus vote *prior* to beginning work on it in the first place.
> >
> >
> >
> >On Wed, Jun 5, 2013 at 11:44 AM, Carlos Santana
> ><cs...@gmail.com>wrote:
> >
> >> +1 on moving to Status:"In Progress" to denote someone is working on it
> >> +1 on allowing time for discussion/code-review between request and
> >>commit
> >>
> >> Sorry trying to learn the Cordova lingo :-)
> >>
> >> --Carlos
> >>
> >>
> >> On Wed, Jun 5, 2013 at 2:32 PM, Jeffrey Heifetz <
> jheifetz@blackberry.com
> >> >wrote:
> >>
> >> > I also think there's value in having some time between posting a
> >> > diff/commit/pull request to the issue and committing to master to
> >>allow
> >> > some discussion.
> >> >
> >> > On 13-06-05 2:25 PM, "Lorin Beer" <lo...@gmail.com> wrote:
> >> >
> >> > >Yes, putting a comment on the issue itself should be sufficient. If
> >> > >you're familiar with the person, im/irc message is appreciated, but
> >> > >not necessary.
> >> > >
> >> > >Generally, Fil is correct. I generally do not mark issues I'm working
> >> > >on as "in progress", but that's something I will immediately adress.
> >> > >
> >> > >On Wed, Jun 5, 2013 at 9:41 AM, Filip Maj <fi...@adobe.com> wrote:
> >> > >> Pretty much.
> >> > >>
> >> > >> My assumption is when looking through JIRA that if an issue isn't
> >>"In
> >> > >> Progress" then I can freely assign to myself and mark it as "In
> >> > >>Progress"
> >> > >> to denote that I am working on it.
> >> > >>
> >> > >> On 6/5/13 9:28 AM, "Carlos Santana" <cs...@gmail.com> wrote:
> >> > >>
> >> > >>>Lorin,
> >> > >>> When you say "ping the person it is assigned to" you mean put a
> >> > >>>comment
> >> > >>>on the JIRA ticket?
> >> > >>>This way everyone is aware that someone is interested on taking
> >>over
> >> the
> >> > >>>ticket or have some input?
> >> > >>>
> >> > >>>Sorry if it was a dumb, question I'm trying to understand the
> >>workflow
> >> > >>>of
> >> > >>>contributing
> >> > >>>
> >> > >>>(open ticket, add comment to JIRA ticket showing interest on
> >>working
> >> the
> >> > >>>ticket, get agreement from assignee, start solving problem, submit
> >> pull
> >> > >>>request, post to dev mailing list for code review)
> >> > >>>
> >> > >>>
> >> > >>>--Carlos
> >> > >>>
> >> > >>>
> >> > >>>On Tue, Jun 4, 2013 at 5:17 PM, Lorin Beer
> >><lo...@gmail.com>
> >> > >>>wrote:
> >> > >>>
> >> > >>>> I've CC'd the relevant parties, but as a reminder of best
> >>practice:
> >> > >>>>
> >> > >>>> regardless of internal company workflow for Cordova contribution,
> >> when
> >> > >>>> tackling an issue filed on jira:
> >> > >>>>
> >> > >>>> 1. if it is not assigned to you, ping the person it is assigned
> >>to
> >> > >>>> 2. discuss assigning to yourself
> >> > >>>> 3. begin solving the issue
> >> > >>>>
> >> > >>>> Keeping work in non-apache repos, and chiming in with a fix once
> >>the
> >> > >>>> issue has already been resolved leads to frustration and
> >>duplication
> >> > >>>> of work.
> >> > >>>>
> >> > >>>> Clear communication is key to cooperating on a project like this,
> >> and
> >> > >>>> that involves letting everyone know what you are working on. The
> >> > >>>> system we employ for that purpose is JIRA.
> >> > >>>>
> >> > >>>> - Lorin
> >> > >>>>
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >>>--
> >> > >>>Carlos Santana
> >> > >>><cs...@gmail.com>
> >> > >>
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > This transmission (including any attachments) may contain confidential
> >> > information, privileged material (including material protected by the
> >> > solicitor-client or other applicable privileges), or constitute
> >> non-public
> >> > information. Any use of this information by anyone other than the
> >> intended
> >> > recipient is prohibited. If you have received this transmission in
> >>error,
> >> > please immediately reply to the sender and delete this information
> >>from
> >> > your system. Use, dissemination, distribution, or reproduction of this
> >> > transmission by unintended recipients is not authorized and may be
> >> unlawful.
> >> >
> >>
> >>
> >>
> >> --
> >> Carlos Santana
> >> <cs...@gmail.com>
> >>
>
>
Re: Cordova vs Company workflow
Posted by Filip Maj <fi...@adobe.com>.
Agree with Lorin, if you are a committer, go ahead and push your changes
but please for the love of god test every change you make. If you cannot
test due to lack of devices, then please for the love of god ask someone
on the list to do the testing for you.
On 6/5/13 4:30 PM, "Lorin Beer" <lo...@gmail.com> wrote:
>-1 for allowing time for discussion/code-review between diff/commit/pull
>request to the issue and committing to master, if I understand the
>suggestion.
>
>For non-committer contributors, yes, this is a natural workflow and
>a necessary step for getting your code into the project in the first
>place.
>
>But the status of committership denotes those that are trusted to push
>commits to master without the contribution being vetted by someone else.
>If
>the commit adds additional functionality or drastically changes existing
>functionality, the workflow is to discuss it on the list and open up a
>lazy
>consensus vote *prior* to beginning work on it in the first place.
>
>
>
>On Wed, Jun 5, 2013 at 11:44 AM, Carlos Santana
><cs...@gmail.com>wrote:
>
>> +1 on moving to Status:"In Progress" to denote someone is working on it
>> +1 on allowing time for discussion/code-review between request and
>>commit
>>
>> Sorry trying to learn the Cordova lingo :-)
>>
>> --Carlos
>>
>>
>> On Wed, Jun 5, 2013 at 2:32 PM, Jeffrey Heifetz <jheifetz@blackberry.com
>> >wrote:
>>
>> > I also think there's value in having some time between posting a
>> > diff/commit/pull request to the issue and committing to master to
>>allow
>> > some discussion.
>> >
>> > On 13-06-05 2:25 PM, "Lorin Beer" <lo...@gmail.com> wrote:
>> >
>> > >Yes, putting a comment on the issue itself should be sufficient. If
>> > >you're familiar with the person, im/irc message is appreciated, but
>> > >not necessary.
>> > >
>> > >Generally, Fil is correct. I generally do not mark issues I'm working
>> > >on as "in progress", but that's something I will immediately adress.
>> > >
>> > >On Wed, Jun 5, 2013 at 9:41 AM, Filip Maj <fi...@adobe.com> wrote:
>> > >> Pretty much.
>> > >>
>> > >> My assumption is when looking through JIRA that if an issue isn't
>>"In
>> > >> Progress" then I can freely assign to myself and mark it as "In
>> > >>Progress"
>> > >> to denote that I am working on it.
>> > >>
>> > >> On 6/5/13 9:28 AM, "Carlos Santana" <cs...@gmail.com> wrote:
>> > >>
>> > >>>Lorin,
>> > >>> When you say "ping the person it is assigned to" you mean put a
>> > >>>comment
>> > >>>on the JIRA ticket?
>> > >>>This way everyone is aware that someone is interested on taking
>>over
>> the
>> > >>>ticket or have some input?
>> > >>>
>> > >>>Sorry if it was a dumb, question I'm trying to understand the
>>workflow
>> > >>>of
>> > >>>contributing
>> > >>>
>> > >>>(open ticket, add comment to JIRA ticket showing interest on
>>working
>> the
>> > >>>ticket, get agreement from assignee, start solving problem, submit
>> pull
>> > >>>request, post to dev mailing list for code review)
>> > >>>
>> > >>>
>> > >>>--Carlos
>> > >>>
>> > >>>
>> > >>>On Tue, Jun 4, 2013 at 5:17 PM, Lorin Beer
>><lo...@gmail.com>
>> > >>>wrote:
>> > >>>
>> > >>>> I've CC'd the relevant parties, but as a reminder of best
>>practice:
>> > >>>>
>> > >>>> regardless of internal company workflow for Cordova contribution,
>> when
>> > >>>> tackling an issue filed on jira:
>> > >>>>
>> > >>>> 1. if it is not assigned to you, ping the person it is assigned
>>to
>> > >>>> 2. discuss assigning to yourself
>> > >>>> 3. begin solving the issue
>> > >>>>
>> > >>>> Keeping work in non-apache repos, and chiming in with a fix once
>>the
>> > >>>> issue has already been resolved leads to frustration and
>>duplication
>> > >>>> of work.
>> > >>>>
>> > >>>> Clear communication is key to cooperating on a project like this,
>> and
>> > >>>> that involves letting everyone know what you are working on. The
>> > >>>> system we employ for that purpose is JIRA.
>> > >>>>
>> > >>>> - Lorin
>> > >>>>
>> > >>>
>> > >>>
>> > >>>
>> > >>>--
>> > >>>Carlos Santana
>> > >>><cs...@gmail.com>
>> > >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > This transmission (including any attachments) may contain confidential
>> > information, privileged material (including material protected by the
>> > solicitor-client or other applicable privileges), or constitute
>> non-public
>> > information. Any use of this information by anyone other than the
>> intended
>> > recipient is prohibited. If you have received this transmission in
>>error,
>> > please immediately reply to the sender and delete this information
>>from
>> > your system. Use, dissemination, distribution, or reproduction of this
>> > transmission by unintended recipients is not authorized and may be
>> unlawful.
>> >
>>
>>
>>
>> --
>> Carlos Santana
>> <cs...@gmail.com>
>>
Re: Cordova vs Company workflow
Posted by Lorin Beer <lo...@gmail.com>.
-1 for allowing time for discussion/code-review between diff/commit/pull
request to the issue and committing to master, if I understand the
suggestion.
For non-committer contributors, yes, this is a natural workflow and
a necessary step for getting your code into the project in the first place.
But the status of committership denotes those that are trusted to push
commits to master without the contribution being vetted by someone else. If
the commit adds additional functionality or drastically changes existing
functionality, the workflow is to discuss it on the list and open up a lazy
consensus vote *prior* to beginning work on it in the first place.
On Wed, Jun 5, 2013 at 11:44 AM, Carlos Santana <cs...@gmail.com>wrote:
> +1 on moving to Status:"In Progress" to denote someone is working on it
> +1 on allowing time for discussion/code-review between request and commit
>
> Sorry trying to learn the Cordova lingo :-)
>
> --Carlos
>
>
> On Wed, Jun 5, 2013 at 2:32 PM, Jeffrey Heifetz <jheifetz@blackberry.com
> >wrote:
>
> > I also think there's value in having some time between posting a
> > diff/commit/pull request to the issue and committing to master to allow
> > some discussion.
> >
> > On 13-06-05 2:25 PM, "Lorin Beer" <lo...@gmail.com> wrote:
> >
> > >Yes, putting a comment on the issue itself should be sufficient. If
> > >you're familiar with the person, im/irc message is appreciated, but
> > >not necessary.
> > >
> > >Generally, Fil is correct. I generally do not mark issues I'm working
> > >on as "in progress", but that's something I will immediately adress.
> > >
> > >On Wed, Jun 5, 2013 at 9:41 AM, Filip Maj <fi...@adobe.com> wrote:
> > >> Pretty much.
> > >>
> > >> My assumption is when looking through JIRA that if an issue isn't "In
> > >> Progress" then I can freely assign to myself and mark it as "In
> > >>Progress"
> > >> to denote that I am working on it.
> > >>
> > >> On 6/5/13 9:28 AM, "Carlos Santana" <cs...@gmail.com> wrote:
> > >>
> > >>>Lorin,
> > >>> When you say "ping the person it is assigned to" you mean put a
> > >>>comment
> > >>>on the JIRA ticket?
> > >>>This way everyone is aware that someone is interested on taking over
> the
> > >>>ticket or have some input?
> > >>>
> > >>>Sorry if it was a dumb, question I'm trying to understand the workflow
> > >>>of
> > >>>contributing
> > >>>
> > >>>(open ticket, add comment to JIRA ticket showing interest on working
> the
> > >>>ticket, get agreement from assignee, start solving problem, submit
> pull
> > >>>request, post to dev mailing list for code review)
> > >>>
> > >>>
> > >>>--Carlos
> > >>>
> > >>>
> > >>>On Tue, Jun 4, 2013 at 5:17 PM, Lorin Beer <lo...@gmail.com>
> > >>>wrote:
> > >>>
> > >>>> I've CC'd the relevant parties, but as a reminder of best practice:
> > >>>>
> > >>>> regardless of internal company workflow for Cordova contribution,
> when
> > >>>> tackling an issue filed on jira:
> > >>>>
> > >>>> 1. if it is not assigned to you, ping the person it is assigned to
> > >>>> 2. discuss assigning to yourself
> > >>>> 3. begin solving the issue
> > >>>>
> > >>>> Keeping work in non-apache repos, and chiming in with a fix once the
> > >>>> issue has already been resolved leads to frustration and duplication
> > >>>> of work.
> > >>>>
> > >>>> Clear communication is key to cooperating on a project like this,
> and
> > >>>> that involves letting everyone know what you are working on. The
> > >>>> system we employ for that purpose is JIRA.
> > >>>>
> > >>>> - Lorin
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>>--
> > >>>Carlos Santana
> > >>><cs...@gmail.com>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > This transmission (including any attachments) may contain confidential
> > information, privileged material (including material protected by the
> > solicitor-client or other applicable privileges), or constitute
> non-public
> > information. Any use of this information by anyone other than the
> intended
> > recipient is prohibited. If you have received this transmission in error,
> > please immediately reply to the sender and delete this information from
> > your system. Use, dissemination, distribution, or reproduction of this
> > transmission by unintended recipients is not authorized and may be
> unlawful.
> >
>
>
>
> --
> Carlos Santana
> <cs...@gmail.com>
>
Re: Cordova vs Company workflow
Posted by Carlos Santana <cs...@gmail.com>.
+1 on moving to Status:"In Progress" to denote someone is working on it
+1 on allowing time for discussion/code-review between request and commit
Sorry trying to learn the Cordova lingo :-)
--Carlos
On Wed, Jun 5, 2013 at 2:32 PM, Jeffrey Heifetz <jh...@blackberry.com>wrote:
> I also think there's value in having some time between posting a
> diff/commit/pull request to the issue and committing to master to allow
> some discussion.
>
> On 13-06-05 2:25 PM, "Lorin Beer" <lo...@gmail.com> wrote:
>
> >Yes, putting a comment on the issue itself should be sufficient. If
> >you're familiar with the person, im/irc message is appreciated, but
> >not necessary.
> >
> >Generally, Fil is correct. I generally do not mark issues I'm working
> >on as "in progress", but that's something I will immediately adress.
> >
> >On Wed, Jun 5, 2013 at 9:41 AM, Filip Maj <fi...@adobe.com> wrote:
> >> Pretty much.
> >>
> >> My assumption is when looking through JIRA that if an issue isn't "In
> >> Progress" then I can freely assign to myself and mark it as "In
> >>Progress"
> >> to denote that I am working on it.
> >>
> >> On 6/5/13 9:28 AM, "Carlos Santana" <cs...@gmail.com> wrote:
> >>
> >>>Lorin,
> >>> When you say "ping the person it is assigned to" you mean put a
> >>>comment
> >>>on the JIRA ticket?
> >>>This way everyone is aware that someone is interested on taking over the
> >>>ticket or have some input?
> >>>
> >>>Sorry if it was a dumb, question I'm trying to understand the workflow
> >>>of
> >>>contributing
> >>>
> >>>(open ticket, add comment to JIRA ticket showing interest on working the
> >>>ticket, get agreement from assignee, start solving problem, submit pull
> >>>request, post to dev mailing list for code review)
> >>>
> >>>
> >>>--Carlos
> >>>
> >>>
> >>>On Tue, Jun 4, 2013 at 5:17 PM, Lorin Beer <lo...@gmail.com>
> >>>wrote:
> >>>
> >>>> I've CC'd the relevant parties, but as a reminder of best practice:
> >>>>
> >>>> regardless of internal company workflow for Cordova contribution, when
> >>>> tackling an issue filed on jira:
> >>>>
> >>>> 1. if it is not assigned to you, ping the person it is assigned to
> >>>> 2. discuss assigning to yourself
> >>>> 3. begin solving the issue
> >>>>
> >>>> Keeping work in non-apache repos, and chiming in with a fix once the
> >>>> issue has already been resolved leads to frustration and duplication
> >>>> of work.
> >>>>
> >>>> Clear communication is key to cooperating on a project like this, and
> >>>> that involves letting everyone know what you are working on. The
> >>>> system we employ for that purpose is JIRA.
> >>>>
> >>>> - Lorin
> >>>>
> >>>
> >>>
> >>>
> >>>--
> >>>Carlos Santana
> >>><cs...@gmail.com>
> >>
>
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>
--
Carlos Santana
<cs...@gmail.com>
Re: Cordova vs Company workflow
Posted by Jeffrey Heifetz <jh...@blackberry.com>.
I also think there's value in having some time between posting a
diff/commit/pull request to the issue and committing to master to allow
some discussion.
On 13-06-05 2:25 PM, "Lorin Beer" <lo...@gmail.com> wrote:
>Yes, putting a comment on the issue itself should be sufficient. If
>you're familiar with the person, im/irc message is appreciated, but
>not necessary.
>
>Generally, Fil is correct. I generally do not mark issues I'm working
>on as "in progress", but that's something I will immediately adress.
>
>On Wed, Jun 5, 2013 at 9:41 AM, Filip Maj <fi...@adobe.com> wrote:
>> Pretty much.
>>
>> My assumption is when looking through JIRA that if an issue isn't "In
>> Progress" then I can freely assign to myself and mark it as "In
>>Progress"
>> to denote that I am working on it.
>>
>> On 6/5/13 9:28 AM, "Carlos Santana" <cs...@gmail.com> wrote:
>>
>>>Lorin,
>>> When you say "ping the person it is assigned to" you mean put a
>>>comment
>>>on the JIRA ticket?
>>>This way everyone is aware that someone is interested on taking over the
>>>ticket or have some input?
>>>
>>>Sorry if it was a dumb, question I'm trying to understand the workflow
>>>of
>>>contributing
>>>
>>>(open ticket, add comment to JIRA ticket showing interest on working the
>>>ticket, get agreement from assignee, start solving problem, submit pull
>>>request, post to dev mailing list for code review)
>>>
>>>
>>>--Carlos
>>>
>>>
>>>On Tue, Jun 4, 2013 at 5:17 PM, Lorin Beer <lo...@gmail.com>
>>>wrote:
>>>
>>>> I've CC'd the relevant parties, but as a reminder of best practice:
>>>>
>>>> regardless of internal company workflow for Cordova contribution, when
>>>> tackling an issue filed on jira:
>>>>
>>>> 1. if it is not assigned to you, ping the person it is assigned to
>>>> 2. discuss assigning to yourself
>>>> 3. begin solving the issue
>>>>
>>>> Keeping work in non-apache repos, and chiming in with a fix once the
>>>> issue has already been resolved leads to frustration and duplication
>>>> of work.
>>>>
>>>> Clear communication is key to cooperating on a project like this, and
>>>> that involves letting everyone know what you are working on. The
>>>> system we employ for that purpose is JIRA.
>>>>
>>>> - Lorin
>>>>
>>>
>>>
>>>
>>>--
>>>Carlos Santana
>>><cs...@gmail.com>
>>
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Cordova vs Company workflow
Posted by Lorin Beer <lo...@gmail.com>.
Yes, putting a comment on the issue itself should be sufficient. If
you're familiar with the person, im/irc message is appreciated, but
not necessary.
Generally, Fil is correct. I generally do not mark issues I'm working
on as "in progress", but that's something I will immediately adress.
On Wed, Jun 5, 2013 at 9:41 AM, Filip Maj <fi...@adobe.com> wrote:
> Pretty much.
>
> My assumption is when looking through JIRA that if an issue isn't "In
> Progress" then I can freely assign to myself and mark it as "In Progress"
> to denote that I am working on it.
>
> On 6/5/13 9:28 AM, "Carlos Santana" <cs...@gmail.com> wrote:
>
>>Lorin,
>> When you say "ping the person it is assigned to" you mean put a comment
>>on the JIRA ticket?
>>This way everyone is aware that someone is interested on taking over the
>>ticket or have some input?
>>
>>Sorry if it was a dumb, question I'm trying to understand the workflow of
>>contributing
>>
>>(open ticket, add comment to JIRA ticket showing interest on working the
>>ticket, get agreement from assignee, start solving problem, submit pull
>>request, post to dev mailing list for code review)
>>
>>
>>--Carlos
>>
>>
>>On Tue, Jun 4, 2013 at 5:17 PM, Lorin Beer <lo...@gmail.com>
>>wrote:
>>
>>> I've CC'd the relevant parties, but as a reminder of best practice:
>>>
>>> regardless of internal company workflow for Cordova contribution, when
>>> tackling an issue filed on jira:
>>>
>>> 1. if it is not assigned to you, ping the person it is assigned to
>>> 2. discuss assigning to yourself
>>> 3. begin solving the issue
>>>
>>> Keeping work in non-apache repos, and chiming in with a fix once the
>>> issue has already been resolved leads to frustration and duplication
>>> of work.
>>>
>>> Clear communication is key to cooperating on a project like this, and
>>> that involves letting everyone know what you are working on. The
>>> system we employ for that purpose is JIRA.
>>>
>>> - Lorin
>>>
>>
>>
>>
>>--
>>Carlos Santana
>><cs...@gmail.com>
>
Re: Cordova vs Company workflow
Posted by Filip Maj <fi...@adobe.com>.
Pretty much.
My assumption is when looking through JIRA that if an issue isn't "In
Progress" then I can freely assign to myself and mark it as "In Progress"
to denote that I am working on it.
On 6/5/13 9:28 AM, "Carlos Santana" <cs...@gmail.com> wrote:
>Lorin,
> When you say "ping the person it is assigned to" you mean put a comment
>on the JIRA ticket?
>This way everyone is aware that someone is interested on taking over the
>ticket or have some input?
>
>Sorry if it was a dumb, question I'm trying to understand the workflow of
>contributing
>
>(open ticket, add comment to JIRA ticket showing interest on working the
>ticket, get agreement from assignee, start solving problem, submit pull
>request, post to dev mailing list for code review)
>
>
>--Carlos
>
>
>On Tue, Jun 4, 2013 at 5:17 PM, Lorin Beer <lo...@gmail.com>
>wrote:
>
>> I've CC'd the relevant parties, but as a reminder of best practice:
>>
>> regardless of internal company workflow for Cordova contribution, when
>> tackling an issue filed on jira:
>>
>> 1. if it is not assigned to you, ping the person it is assigned to
>> 2. discuss assigning to yourself
>> 3. begin solving the issue
>>
>> Keeping work in non-apache repos, and chiming in with a fix once the
>> issue has already been resolved leads to frustration and duplication
>> of work.
>>
>> Clear communication is key to cooperating on a project like this, and
>> that involves letting everyone know what you are working on. The
>> system we employ for that purpose is JIRA.
>>
>> - Lorin
>>
>
>
>
>--
>Carlos Santana
><cs...@gmail.com>
Re: Cordova vs Company workflow
Posted by Carlos Santana <cs...@gmail.com>.
Lorin,
When you say "ping the person it is assigned to" you mean put a comment
on the JIRA ticket?
This way everyone is aware that someone is interested on taking over the
ticket or have some input?
Sorry if it was a dumb, question I'm trying to understand the workflow of
contributing
(open ticket, add comment to JIRA ticket showing interest on working the
ticket, get agreement from assignee, start solving problem, submit pull
request, post to dev mailing list for code review)
--Carlos
On Tue, Jun 4, 2013 at 5:17 PM, Lorin Beer <lo...@gmail.com> wrote:
> I've CC'd the relevant parties, but as a reminder of best practice:
>
> regardless of internal company workflow for Cordova contribution, when
> tackling an issue filed on jira:
>
> 1. if it is not assigned to you, ping the person it is assigned to
> 2. discuss assigning to yourself
> 3. begin solving the issue
>
> Keeping work in non-apache repos, and chiming in with a fix once the
> issue has already been resolved leads to frustration and duplication
> of work.
>
> Clear communication is key to cooperating on a project like this, and
> that involves letting everyone know what you are working on. The
> system we employ for that purpose is JIRA.
>
> - Lorin
>
--
Carlos Santana
<cs...@gmail.com>