cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Cordova Issue Workflow
Date Tue, 22 Oct 2013 15:45:13 GMT
Quick side note: Thanks for taking this on Josh.

Cordova is kind of an older project and in that maturity things seem to sag
and wilt without exercise: especially wiki articles about our process!


On Tue, Oct 22, 2013 at 8:17 AM, Andrew Grieve <agrieve@chromium.org> wrote:

> That's true. It's also the case that when a bug is brand new, or is stale
> (hasn't been updated in over a week), that we tend to just change assignees
> without any sort of comment.
>
> So, how about we say Assignee means something only when it was set within
> the past week?
>
>
> On Tue, Oct 22, 2013 at 11:08 AM, Jeffrey Heifetz
> <jheifetz@blackberry.com>wrote:
>
> > I thought that if an issue is assigned it means nothing but if it's
> marked
> > as in progress then someone is working on it.‎ There are still components
> > with default assignees I thought.
> >
> > Sent from my BlackBerry 10 smartphone on the Rogers network.
> >   Original Message
> > From: Andrew Grieve
> > Sent: Tuesday, October 22, 2013 11:00 AM
> > To: dev
> > Reply To: dev@cordova.apache.org
> > Subject: Re: Cordova Issue Workflow
> >
> >
> > 1. Creating/finding an issue is buried in text in the middle of the
> "About
> > > Commit Messages" -- that can't possibly be where one creates or finds a
> > > bug in anyone's actual workflow.
> > >
> >
> > Breaking out the issue workflow makes sense to me.
> >
> >
> > > 2. It doesn't say how/when issues are updated.
> > >
> > Committers will be emailed whenever an issue is created. They will often
> be
> > updated when someone has looked at it for the first time
> >
> > If you want to be able to update JIRA issues, you need to ask for
> > permissions to do so on the mailing-list. You don't need to be a
> committer
> > to get JIRA access.
> >
> >
> > > 3. It doesn't say if one should try to have an issue assigned if
> they're
> > > working on it.
> > >
> > If someone gets assigned the issue, that means they intend to work on it
> > (although not necessarily right away).
> >
> > If you want to work on an issue that's assigned to someone else, then you
> > should add a comment to the issue stating your intention, but don't need
> to
> > wait for a response. The chance of two people duplicating work is very
> low.
> >
> > 4. "Review Board is a tool for committers to review each others' changes.
> > > As a contributor generally you won't use Review Board - the pull
> request
> > > should be sufficient." -- There's no link to review board.
> > >
> >
> > http://reviews.apache.org
> >
> > Uploading patches (via `git format-patch`) to JIRA issues is another
> valid
> > alternative to pull requests. Pasting code into JIRA issues works as
> well,
> > although you will then not be given authorship of the patch.
> >
> > 5. It doesn't explain the Version fields (found/fixed) -- neither who
> > > should fill them out/according to whatŠ
> > >
> >
> > Version fixed shouldn't be touched until the bug is fixed, and a
> committer
> > will fill it in.
> > Version found often doesn't make sense in our multi-repo multi-version
> > world anymore. If the bug does map nicely to a cadence release (e.g. 3.1)
> > then feel free to fill it in. Otherwise, it's just as helpful to say what
> > versions of things you tested with in the bug description.
> >
> >
> > > 6. It doesn't explain how an issue should be resolved / what steps
> should
> > > be taken. There seems to be a difference between something being
> "Fixed"
> > > and something being "Resolved".
> >
> >
> > You can "Resolve" an issue as "Not Fixed", or "Duplicate". There is also
> a
> > difference between "Fixed" and "Closed", but we don't treat them as any
> > different.
> >
> >
> >
> >
> >
> > On Tue, Oct 22, 2013 at 10:16 AM, Josh Soref <jsoref@blackberry.com>
> > wrote:
> >
> > > On 10/22/13 10:07 AM, "Andrew Grieve" <agrieve@chromium.org> wrote:
> > > >Great feedback Josh!
> > > >
> > > >Are you looking for answers to these shortcomings?
> > >
> > > Sadly, I don't think I know the answer to most of these. If people give
> > me
> > > answers, I'll be happy to add them to the wiki.
> > >
> > >
> > > I suspect I can find review board...
> > >
> > > There's also a structural problem. I don't think that the "Process of
> > > Contributing" should really be in the same page as "IssueWorkflow".
> > >
> > > If people agree, I can split out IssueWorkflow eventuallyŠ
> > >
> > > Getting an apache.org account/doing the CLA stuff is something you'll
> do
> > > once. But touching issues is something you'll do many times. You
> > shouldn't
> > > have to read the CLA boilerplate to re-view the workflow for working on
> > > issues.
> > >
> > > > If you're just looking for a +1 please improve the wiki, then... +1!
> > >
> > > I'll start nowise...
> > >
> > > ---------------------------------------------------------------------
> > > 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.
> > >
> > >
> > ---------------------------------------------------------------------
> > 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.
> >
>

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