You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Josh Soref <js...@blackberry.com> on 2013/10/22 02:55:51 UTC
Cordova Issue Workflow
Google <https://www.google.ca/?q=cordova+issue+workflow> tells me that
there's a ContributorWorkflow:
http://wiki.apache.org/cordova/ContributorWorkflow
But:
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.
2. It doesn't say how/when issues are updated.
3. It doesn't say if one should try to have an issue assigned if they're
working on it.
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.
5. It doesn't explain the Version fields (found/fixed) -- neither who
should fill them out/according to whatŠ
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".
---------------------------------------------------------------------
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 Issue Workflow
Posted by Andrew Grieve <ag...@chromium.org>.
Pages look great Josh!
On Wed, Oct 23, 2013 at 10:36 PM, Andrew Grieve <ag...@chromium.org>wrote:
> Shoot. Just ignore that "Not" :P.
>
>
> On Wed, Oct 23, 2013 at 8:11 PM, Josh Soref <js...@blackberry.com> wrote:
>
>> On 10/22/13 10:59 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
>> >You can "Resolve" an issue as "Not Fixed", or "Duplicate".
>>
>> Duplicate I understand. What's Not Fixed for?
>>
>> (I'm working on integrating the input today)
>>
>> ---------------------------------------------------------------------
>> 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 Issue Workflow
Posted by Andrew Grieve <ag...@chromium.org>.
Shoot. Just ignore that "Not" :P.
On Wed, Oct 23, 2013 at 8:11 PM, Josh Soref <js...@blackberry.com> wrote:
> On 10/22/13 10:59 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
> >You can "Resolve" an issue as "Not Fixed", or "Duplicate".
>
> Duplicate I understand. What's Not Fixed for?
>
> (I'm working on integrating the input today)
>
> ---------------------------------------------------------------------
> 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 Issue Workflow
Posted by Brian LeRoux <b...@brian.io>.
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 <ag...@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
> <jh...@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 <js...@blackberry.com>
> > wrote:
> >
> > > On 10/22/13 10:07 AM, "Andrew Grieve" <ag...@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.
> >
>
Re: Cordova Issue Workflow
Posted by Andrew Grieve <ag...@chromium.org>.
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
<jh...@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 <js...@blackberry.com>
> wrote:
>
> > On 10/22/13 10:07 AM, "Andrew Grieve" <ag...@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.
>
Re: Cordova Issue Workflow
Posted by Jeffrey Heifetz <jh...@blackberry.com>.
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 <js...@blackberry.com> wrote:
> On 10/22/13 10:07 AM, "Andrew Grieve" <ag...@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.
Re: Cordova Issue Workflow
Posted by Josh Soref <js...@blackberry.com>.
Ok, I've done a first pass on thisŠ
https://wiki.apache.org/cordova/ContributorWorkflow
+ is now a short and fairly easy to read page
- there's too much text at the bottom (tl;dr - it's about editing the Wiki
XXX fix me)
https://wiki.apache.org/cordova/IssueWorkflow
+ now focused on Issue bits
- there's some duplicated text at the bottom (XXX fix me)
https://wiki.apache.org/cordova/GitWorkflow
+ now has the extra Git bits
---------------------------------------------------------------------
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 Issue Workflow
Posted by Josh Soref <js...@blackberry.com>.
On 10/22/13 10:59 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
>You can "Resolve" an issue as "Not Fixed", or "Duplicate".
Duplicate I understand. What's Not Fixed for?
(I'm working on integrating the input today)
---------------------------------------------------------------------
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 Issue Workflow
Posted by Andrew Grieve <ag...@chromium.org>.
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 <js...@blackberry.com> wrote:
> On 10/22/13 10:07 AM, "Andrew Grieve" <ag...@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.
>
>
Re: Cordova Issue Workflow
Posted by Josh Soref <js...@blackberry.com>.
On 10/22/13 10:07 AM, "Andrew Grieve" <ag...@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.
Re: Cordova Issue Workflow
Posted by Andrew Grieve <ag...@chromium.org>.
Great feedback Josh!
Are you looking for answers to these shortcomings? If you're just looking
for a +1 please improve the wiki, then... +1!
On Mon, Oct 21, 2013 at 8:55 PM, Josh Soref <js...@blackberry.com> wrote:
> Google <https://www.google.ca/?q=cordova+issue+workflow> tells me that
> there's a ContributorWorkflow:
> http://wiki.apache.org/cordova/ContributorWorkflow
>
> But:
> 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.
> 2. It doesn't say how/when issues are updated.
> 3. It doesn't say if one should try to have an issue assigned if they're
> working on it.
> 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.
> 5. It doesn't explain the Version fields (found/fixed) -- neither who
> should fill them out/according to whatŠ
> 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".
>
> ---------------------------------------------------------------------
> 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.
>
>