cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: Cordova vs Company workflow
Date Wed, 05 Jun 2013 23:36:54 GMT
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" <fil@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" <lorin.beer.dev@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
> ><csantana23@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" <lorin.beer.dev@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 <fil@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" <csantana23@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
> >><lorin.beer.dev@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
> >> > >>><csantana23@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
> >> <csantana23@gmail.com>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message