cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Cordova Issue Workflow
Date Tue, 22 Oct 2013 15:17:16 GMT
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