cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <>
Subject Re: Cordova Issue Workflow
Date Tue, 22 Oct 2013 14:59:54 GMT
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.

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

On Tue, Oct 22, 2013 at 10:16 AM, Josh Soref <> wrote:

> On 10/22/13 10:07 AM, "Andrew Grieve" <> 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 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.

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