You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2009/09/03 10:12:57 UTC
JIRA "needs documentation" state?
Hi,
I have reopened https://issues.apache.org/jira/browse/SLING-922 to
remind us to document this feature.
We could also create another issue ("document SLING-922") for that -
or does JIRA allow for "needs documentation" (and maybe "needs
automated tests") states for such issues, where the coding is done but
docs and/or tests are still missing.
Does anyone know? If not I'll try to find out how JIRA could help manage this.
-Bertrand
Re: JIRA "needs documentation" state?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Carsten Ziegeler schrieb:
> Felix Meschberger wrote:
>> I will create a documentation page on this.
I have created the page at [1]. Within an hour or two, this hit the main
site.
>>
> Cool, thanks - what about a "fix broken" state for closed issues that
> are broken?
It looks like the resolution of an issue can only be modified when
reopening the issue and resolving it with another resolution. It might
be possible to create a screen, which allows to reset the resolution
type of closed issues.
Not sure, though whether this feature is really so important as to go
this route....
Regards
Felix
[1] http://cwiki.apache.org/SLINGxSITE/issue-tracker.html
Re: JIRA "needs documentation" state?
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> Hi,
>
> I have now created a workflow for SLING as follows:
>
> * 3 new states
> Documentation Required
> can transition to Resolved
> Testcases Required
> can transition to Resolved
> Documentation/Testcases Required
> can transition to Documentation Required
> can transition to Testcase Required
> can transition to Resolved
>
> * Issues in progress can transition to
> - Resolved
> - Documentation Required
> - Testcase Required
> - Documentation/Testcase Required
>
> * Closed issues cannot be reopened
> The idea is, that closed issues are part of a
> released product and thus issues occurring in the
> released product should raise new issues (may link
> to old ones, though).
>
> As a consequence of the last point, issues should generally be resolved
> only. The release manager will then care to close the issues after release.
>
> I will create a documentation page on this.
>
Cool, thanks - what about a "fix broken" state for closed issues that
are broken?
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: JIRA "needs documentation" state?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
I have now created a workflow for SLING as follows:
* 3 new states
Documentation Required
can transition to Resolved
Testcases Required
can transition to Resolved
Documentation/Testcases Required
can transition to Documentation Required
can transition to Testcase Required
can transition to Resolved
* Issues in progress can transition to
- Resolved
- Documentation Required
- Testcase Required
- Documentation/Testcase Required
* Closed issues cannot be reopened
The idea is, that closed issues are part of a
released product and thus issues occurring in the
released product should raise new issues (may link
to old ones, though).
As a consequence of the last point, issues should generally be resolved
only. The release manager will then care to close the issues after release.
I will create a documentation page on this.
Regards
Felix
Bertrand Delacretaz schrieb:
> Hi,
>
> I have reopened https://issues.apache.org/jira/browse/SLING-922 to
> remind us to document this feature.
>
> We could also create another issue ("document SLING-922") for that -
> or does JIRA allow for "needs documentation" (and maybe "needs
> automated tests") states for such issues, where the coding is done but
> docs and/or tests are still missing.
>
> Does anyone know? If not I'll try to find out how JIRA could help manage this.
>
> -Bertrand
>
Re: JIRA "needs documentation" state?
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Sep 3, 2009 at 11:09 AM, Ian Boston<ie...@tfd.co.uk> wrote:
> yes +1, provided that the workflow transitions are simple and easy to use. I
> used a more complex Jira setup where it was never clear how and where to
> transition to.... it was a nightmare to use without a cheat sheet on the
> wall.
In general new workflow states are only useful if there are people who
rely on reports like the "Project Summary" on the Jira project page to
keep track of issues in specific states. If that's not the case, then
you could achieve the same functionality much easier by simply keeping
the issue open and adding a comment that tests or documentation are
still needed before the issue can be closed.
BR,
Jukka Zitting
Re: JIRA "needs documentation" state?
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Sep 3, 2009 at 2:15 PM, Jukka Zitting<ju...@gmail.com> wrote:
> On Thu, Sep 3, 2009 at 12:26 PM, Bertrand
> Delacretaz<bd...@codeconsult.ch> wrote:
>> I'd suggest leaving all transitions possible, except maybe going back
>> to "Open" from the "needs X" states.
>
> It should always be possible to go back to Open from any other state
> than Closed. That way you don't need to create a new issue if you find
> out that an unreleased fix needs to be changed in some way.
Hmm, actually that's what the Reopened state is for... :-)
BR,
Jukka Zitting
Re: JIRA "needs documentation" state?
Posted by Bertrand Delacretaz <bd...@gmail.com>.
Hi,
On Thu, Sep 3, 2009 at 2:15 PM, Jukka Zitting<ju...@gmail.com> wrote:
> On Thu, Sep 3, 2009 at 12:26 PM, Bertrand
> Delacretaz<bd...@codeconsult.ch> wrote:
>> I'd suggest leaving all transitions possible, except maybe going back
>> to "Open" from the "needs X" states.
>
> It should always be possible to go back to Open from any other state
> than Closed. That way you don't need to create a new issue if you find
> out that an unreleased fix needs to be changed in some way...
Ok, let's leave all transitions open then!
-Bertrand
Re: JIRA "needs documentation" state?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Bertrand Delacretaz schrieb:
> Hi,
>
> On Fri, Sep 4, 2009 at 2:31 PM, Felix Meschberger<fm...@gmail.com> wrote:
>> ...At the same time I think it would be a good idea to
>> prevent bugs from being reopened as has been set on Jackrabbit and other
>> projects...
>
> What's the idea behind this? Force people to reopen new issues if a
> problem is not really solved?
The opposite: prevent issues from being reopened, once closed. THis
should force people to create new issues. This is particularly important
once closed issues are "released".
Regards
Felix
Re: JIRA "needs documentation" state?
Posted by Bertrand Delacretaz <bd...@gmail.com>.
Hi,
On Sat, Sep 5, 2009 at 7:34 PM, Carsten Ziegeler<cz...@apache.org> wrote:
> ...I personally don't think that we need new states for documentation or
> testing. Usually people are either doing this anyway, or are never doing
> it - so a new state doesn't help....
Like Mike, I think it *is* possible for people to write docs later ;-)
And I have been adding tests later to some feature that didn't have
automated tests - it's a great way of understanding how things work,
so I like to couple my "learning" and "improving tests" tasks when
possible.
And those new states won't cause any harm, just don't use them if you
don't think they are needed.
-Bertrand
Re: JIRA "needs documentation" state?
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
>
> I think, issues resolved/closed and included in a release must not be
> opened anymore. Otherwise we come into states where issues spawn more
> than one release and it is not clear anymore, what part of the issue
> work is in which release.
>
> Rather I think for such situations we should:
>
> * create a new issue
> * link the two issues
> * optionally change the resolution of the closed fix to
> something "not completely fixed, see linked issue)
Yes, I'm just thinking of users looking into an issue which shows "fixed
in version x.y" and they think it's fixed in version x.y - usually you
don't look immediately at linked bugs. So a new resolution would make
sense - especially as this bug is not fixed :)
>> I personally don't think that we need new states for documentation or
>> testing. Usually people are either doing this anyway, or are never doing
>> it - so a new state doesn't help.
>
> It does not force us to do tests or documentation, but it may remind us
> to not forget about it (as was the case here).
Yes, but we should be carefull as this should not block a release :)
> It may not completely help, but I suppose it won't harm either. On the
> other hand it may help with documentation, in that we can consider
> documentation state issues specially.
Yes, it doesn't harm - the only problem I see (and it might be minor) is
that other projects at Apache don't have these states.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
RE: JIRA "needs documentation" state?
Posted by Mike Müller <mi...@mysign.ch>.
Hi
> Hi,
>
> Carsten Ziegeler schrieb:
> > Bertrand Delacretaz wrote:
> >> On Fri, Sep 4, 2009 at 2:48 PM, Jukka
> Zitting<ju...@gmail.com> wrote:
> >>> On Fri, Sep 4, 2009 at 2:44 PM, Bertrand
> >>> Delacretaz<bd...@gmail.com> wrote:
> >>>> On Fri, Sep 4, 2009 at 2:31 PM, Felix
> Meschberger<fm...@gmail.com> wrote:
> >>>>> ...At the same time I think it would be a good idea to
> >>>>> prevent bugs from being reopened as has been set on
> Jackrabbit and other
> >>>>> projects...
> >>>> What's the idea behind this? Force people to reopen new
> issues if a
> >>>> problem is not really solved?
> >>> In Jackrabbit we mark issues as Resolved when the fix is
> in trunk, and
> >>> Closed when the fix has been released.
> >>>
> >>> Once the fix has been released, it can no longer be
> changed and thus
> >>> it's better to prevent people from reopening the issue. A
> new issue
> >>> with the correct Affects Version setting should be created in such
> >>> cases.
> >> Ok, I see the idea and agree. Though...if someone
> mistakenly changes
> >> an issue to "Closed", is it dead? Or can an administrator change it
> >> back?
> >>
> > Hmm, usually I close an issue if I think it's completly
> fixed :) But I
> > usually do this before the release. Maybe I'm using a wrong
> workflow...
> >
> > But anyway, I think it should always be possible to reopen
> a bug, even
> > if the fix has been released.
> >
> > But on the other hand, I guess, we all are working slightly
> different
> > with (Jira) issues which makes it even harder :)
>
> I think, issues resolved/closed and included in a release must not be
> opened anymore. Otherwise we come into states where issues spawn more
> than one release and it is not clear anymore, what part of the issue
> work is in which release.
>
> Rather I think for such situations we should:
>
> * create a new issue
> * link the two issues
> * optionally change the resolution of the closed fix to
> something "not completely fixed, see linked issue)
>
> >
> > I personally don't think that we need new states for
> documentation or
> > testing. Usually people are either doing this anyway, or
> are never doing
> > it - so a new state doesn't help.
>
> It does not force us to do tests or documentation, but it may
> remind us
> to not forget about it (as was the case here).
>
> It may not completely help, but I suppose it won't harm either. On the
> other hand it may help with documentation, in that we can consider
> documentation state issues specially.
IMHO it *will* help. At the moment I just let mails from the list in the
state of unread to not forget to document something (in many cases it's an
JIRA issue which is closed...). At the moment I've got 191 such unread
marked mails which isn't handy any more (and a lot to do as well ;-)).
If it does not harm I definitifely vote for these new states.
best regards
mike
Re: JIRA "needs documentation" state?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Carsten Ziegeler schrieb:
> Bertrand Delacretaz wrote:
>> On Fri, Sep 4, 2009 at 2:48 PM, Jukka Zitting<ju...@gmail.com> wrote:
>>> On Fri, Sep 4, 2009 at 2:44 PM, Bertrand
>>> Delacretaz<bd...@gmail.com> wrote:
>>>> On Fri, Sep 4, 2009 at 2:31 PM, Felix Meschberger<fm...@gmail.com> wrote:
>>>>> ...At the same time I think it would be a good idea to
>>>>> prevent bugs from being reopened as has been set on Jackrabbit and other
>>>>> projects...
>>>> What's the idea behind this? Force people to reopen new issues if a
>>>> problem is not really solved?
>>> In Jackrabbit we mark issues as Resolved when the fix is in trunk, and
>>> Closed when the fix has been released.
>>>
>>> Once the fix has been released, it can no longer be changed and thus
>>> it's better to prevent people from reopening the issue. A new issue
>>> with the correct Affects Version setting should be created in such
>>> cases.
>> Ok, I see the idea and agree. Though...if someone mistakenly changes
>> an issue to "Closed", is it dead? Or can an administrator change it
>> back?
>>
> Hmm, usually I close an issue if I think it's completly fixed :) But I
> usually do this before the release. Maybe I'm using a wrong workflow...
>
> But anyway, I think it should always be possible to reopen a bug, even
> if the fix has been released.
>
> But on the other hand, I guess, we all are working slightly different
> with (Jira) issues which makes it even harder :)
I think, issues resolved/closed and included in a release must not be
opened anymore. Otherwise we come into states where issues spawn more
than one release and it is not clear anymore, what part of the issue
work is in which release.
Rather I think for such situations we should:
* create a new issue
* link the two issues
* optionally change the resolution of the closed fix to
something "not completely fixed, see linked issue)
>
> I personally don't think that we need new states for documentation or
> testing. Usually people are either doing this anyway, or are never doing
> it - so a new state doesn't help.
It does not force us to do tests or documentation, but it may remind us
to not forget about it (as was the case here).
It may not completely help, but I suppose it won't harm either. On the
other hand it may help with documentation, in that we can consider
documentation state issues specially.
Regards
Felix
Re: JIRA "needs documentation" state?
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote:
> On Fri, Sep 4, 2009 at 2:48 PM, Jukka Zitting<ju...@gmail.com> wrote:
>> On Fri, Sep 4, 2009 at 2:44 PM, Bertrand
>> Delacretaz<bd...@gmail.com> wrote:
>>> On Fri, Sep 4, 2009 at 2:31 PM, Felix Meschberger<fm...@gmail.com> wrote:
>>>> ...At the same time I think it would be a good idea to
>>>> prevent bugs from being reopened as has been set on Jackrabbit and other
>>>> projects...
>>> What's the idea behind this? Force people to reopen new issues if a
>>> problem is not really solved?
>> In Jackrabbit we mark issues as Resolved when the fix is in trunk, and
>> Closed when the fix has been released.
>>
>> Once the fix has been released, it can no longer be changed and thus
>> it's better to prevent people from reopening the issue. A new issue
>> with the correct Affects Version setting should be created in such
>> cases.
>
> Ok, I see the idea and agree. Though...if someone mistakenly changes
> an issue to "Closed", is it dead? Or can an administrator change it
> back?
>
Hmm, usually I close an issue if I think it's completly fixed :) But I
usually do this before the release. Maybe I'm using a wrong workflow...
But anyway, I think it should always be possible to reopen a bug, even
if the fix has been released.
But on the other hand, I guess, we all are working slightly different
with (Jira) issues which makes it even harder :)
I personally don't think that we need new states for documentation or
testing. Usually people are either doing this anyway, or are never doing
it - so a new state doesn't help.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: JIRA "needs documentation" state?
Posted by Felix Meschberger <fm...@gmail.com>.
We might just have to educate us and people to not close issues -- so
rather than writing "close if satisfied", we would write "reopen if
unsatisifed"
Regards
Felix
Jukka Zitting schrieb:
> Hi,
>
> On Fri, Sep 4, 2009 at 3:00 PM, Bertrand
> Delacretaz<bd...@gmail.com> wrote:
>> Ok, I see the idea and agree. Though...if someone mistakenly changes
>> an issue to "Closed", is it dead? Or can an administrator change it
>> back?
>
> Not without temporarily tweaking the workflow settings.
>
> In practice this hasn't been a problem.
>
> BR,
>
> Jukka Zitting
>
Re: JIRA "needs documentation" state?
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Sep 4, 2009 at 3:00 PM, Bertrand
Delacretaz<bd...@gmail.com> wrote:
> Ok, I see the idea and agree. Though...if someone mistakenly changes
> an issue to "Closed", is it dead? Or can an administrator change it
> back?
Not without temporarily tweaking the workflow settings.
In practice this hasn't been a problem.
BR,
Jukka Zitting
Re: JIRA "needs documentation" state?
Posted by Bertrand Delacretaz <bd...@gmail.com>.
On Fri, Sep 4, 2009 at 2:48 PM, Jukka Zitting<ju...@gmail.com> wrote:
> On Fri, Sep 4, 2009 at 2:44 PM, Bertrand
> Delacretaz<bd...@gmail.com> wrote:
>> On Fri, Sep 4, 2009 at 2:31 PM, Felix Meschberger<fm...@gmail.com> wrote:
>>> ...At the same time I think it would be a good idea to
>>> prevent bugs from being reopened as has been set on Jackrabbit and other
>>> projects...
>>
>> What's the idea behind this? Force people to reopen new issues if a
>> problem is not really solved?
>
> In Jackrabbit we mark issues as Resolved when the fix is in trunk, and
> Closed when the fix has been released.
>
> Once the fix has been released, it can no longer be changed and thus
> it's better to prevent people from reopening the issue. A new issue
> with the correct Affects Version setting should be created in such
> cases.
Ok, I see the idea and agree. Though...if someone mistakenly changes
an issue to "Closed", is it dead? Or can an administrator change it
back?
-Bertrand
Re: JIRA "needs documentation" state?
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Sep 4, 2009 at 2:44 PM, Bertrand
Delacretaz<bd...@gmail.com> wrote:
> On Fri, Sep 4, 2009 at 2:31 PM, Felix Meschberger<fm...@gmail.com> wrote:
>> ...At the same time I think it would be a good idea to
>> prevent bugs from being reopened as has been set on Jackrabbit and other
>> projects...
>
> What's the idea behind this? Force people to reopen new issues if a
> problem is not really solved?
In Jackrabbit we mark issues as Resolved when the fix is in trunk, and
Closed when the fix has been released.
Once the fix has been released, it can no longer be changed and thus
it's better to prevent people from reopening the issue. A new issue
with the correct Affects Version setting should be created in such
cases.
BR,
Jukka Zitting
Re: JIRA "needs documentation" state?
Posted by Bertrand Delacretaz <bd...@gmail.com>.
Hi,
On Fri, Sep 4, 2009 at 2:31 PM, Felix Meschberger<fm...@gmail.com> wrote:
> ...At the same time I think it would be a good idea to
> prevent bugs from being reopened as has been set on Jackrabbit and other
> projects...
What's the idea behind this? Force people to reopen new issues if a
problem is not really solved?
-Bertrand
Re: JIRA "needs documentation" state?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Betrand,
Bertrand Delacretaz schrieb:
> Hi,
>
> Seems like we agree to add these states to JIRA's Sling workflow:
>
> "Needs documentation/tests"
> "Needs documentation"
> "Needs tests"
>
> Transition from any state to these is allowed, and transitions from
> these states to any other state as well.
>
> Does someone here have karma to change this configuration, or do I
> need to ask infra?
> I don't think I have that, don't see any workflows option on my JIRA
> Administration page.
I could do that. At the same time I think it would be a good idea to
prevent bugs from being reopened as has been set on Jackrabbit and other
projects.
WDYT ?
Regards
Felix
Re: JIRA "needs documentation" state?
Posted by Bertrand Delacretaz <bd...@gmail.com>.
Hi,
Seems like we agree to add these states to JIRA's Sling workflow:
"Needs documentation/tests"
"Needs documentation"
"Needs tests"
Transition from any state to these is allowed, and transitions from
these states to any other state as well.
Does someone here have karma to change this configuration, or do I
need to ask infra?
I don't think I have that, don't see any workflows option on my JIRA
Administration page.
-Bertrand
Re: JIRA "needs documentation" state?
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Sep 3, 2009 at 12:26 PM, Bertrand
Delacretaz<bd...@codeconsult.ch> wrote:
> I'd suggest leaving all transitions possible, except maybe going back
> to "Open" from the "needs X" states.
It should always be possible to go back to Open from any other state
than Closed. That way you don't need to create a new issue if you find
out that an unreleased fix needs to be changed in some way.
BR,
Jukka Zitting
Re: JIRA "needs documentation" state?
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
On Thu, Sep 3, 2009 at 11:09 AM, Ian Boston<ie...@tfd.co.uk> wrote:
> ...yes +1, provided that the workflow transitions are simple and easy to use. I
> used a more complex Jira setup where it was never clear how and where to
> transition to.... it was a nightmare to use without a cheat sheet on the
> wall....
I'd suggest leaving all transitions possible, except maybe going back
to "Open" from the "needs X" states.
No need to restrict anything, as Jukka indicates the goal is to better
keep track of why an issue is still open.
-Bertrand
RE: JIRA "needs documentation" state?
Posted by Mike Müller <mi...@mysign.ch>.
> On 3 Sep 2009, at 10:04, Vidar Ramdal wrote:
>
> > On Thu, Sep 3, 2009 at 10:38 AM, Bertrand
> > Delacretaz<bd...@gmail.com> wrote:
> >> Hi,
> >>
> >> On Thu, Sep 3, 2009 at 10:22 AM, Jukka
> Zitting<jukka.zitting@gmail.com
> >> > wrote:
> >>> On Thu, Sep 3, 2009 at 10:12 AM, Bertrand
> >>> Delacretaz<bd...@apache.org> wrote:
> >>>> ...does JIRA allow for "needs documentation" (and maybe "needs
> >>>> automated tests") states for such issues, where the coding is
> >>>> done but
> >>>> docs and/or tests are still missing.
> >>>>
> >>> ...It's possible to specify a custom Jira workflow for something
> >>> like
> >>> this. Just define the extra issue states you need and the
> permitted
> >>> transitions between the states. The default states used
> currently
> >>> are:
> >>> Open, In Progress, Reopened, Resolved, Closed....
> >>
> >> I'd suggest three new states then
> >>
> >> "Needs documentation/tests"
> >> "Needs documentation"
> >> "Needs tests"
> >>
> >> Transition from any state to these would be allowed, and these can
> >> transition to any state except "Open".
> >>
> >> What do people think?
> >
> > +1
> >
>
> yes +1, provided that the workflow transitions are simple and
> easy to
> use. I used a more complex Jira setup where it was never
> clear how and
> where to transition to.... it was a nightmare to use without a cheat
> sheet on the wall.
+1
best regards
mike
Re: JIRA "needs documentation" state?
Posted by Ian Boston <ie...@tfd.co.uk>.
On 3 Sep 2009, at 10:04, Vidar Ramdal wrote:
> On Thu, Sep 3, 2009 at 10:38 AM, Bertrand
> Delacretaz<bd...@gmail.com> wrote:
>> Hi,
>>
>> On Thu, Sep 3, 2009 at 10:22 AM, Jukka Zitting<jukka.zitting@gmail.com
>> > wrote:
>>> On Thu, Sep 3, 2009 at 10:12 AM, Bertrand
>>> Delacretaz<bd...@apache.org> wrote:
>>>> ...does JIRA allow for "needs documentation" (and maybe "needs
>>>> automated tests") states for such issues, where the coding is
>>>> done but
>>>> docs and/or tests are still missing.
>>>>
>>> ...It's possible to specify a custom Jira workflow for something
>>> like
>>> this. Just define the extra issue states you need and the permitted
>>> transitions between the states. The default states used currently
>>> are:
>>> Open, In Progress, Reopened, Resolved, Closed....
>>
>> I'd suggest three new states then
>>
>> "Needs documentation/tests"
>> "Needs documentation"
>> "Needs tests"
>>
>> Transition from any state to these would be allowed, and these can
>> transition to any state except "Open".
>>
>> What do people think?
>
> +1
>
yes +1, provided that the workflow transitions are simple and easy to
use. I used a more complex Jira setup where it was never clear how and
where to transition to.... it was a nightmare to use without a cheat
sheet on the wall.
>
> --
> Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
> Sommerrogata 13-15, N-0255 Oslo, Norway
> + 47 22 00 84 00 / +47 21 531941, ext 2070
Re: JIRA "needs documentation" state?
Posted by Vidar Ramdal <vi...@idium.no>.
On Thu, Sep 3, 2009 at 10:38 AM, Bertrand
Delacretaz<bd...@gmail.com> wrote:
> Hi,
>
> On Thu, Sep 3, 2009 at 10:22 AM, Jukka Zitting<ju...@gmail.com> wrote:
>> On Thu, Sep 3, 2009 at 10:12 AM, Bertrand
>> Delacretaz<bd...@apache.org> wrote:
>>> ...does JIRA allow for "needs documentation" (and maybe "needs
>>> automated tests") states for such issues, where the coding is done but
>>> docs and/or tests are still missing.
>>>
>> ...It's possible to specify a custom Jira workflow for something like
>> this. Just define the extra issue states you need and the permitted
>> transitions between the states. The default states used currently are:
>> Open, In Progress, Reopened, Resolved, Closed....
>
> I'd suggest three new states then
>
> "Needs documentation/tests"
> "Needs documentation"
> "Needs tests"
>
> Transition from any state to these would be allowed, and these can
> transition to any state except "Open".
>
> What do people think?
+1
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070
unsubscribe (was: JIRA "needs documentation" state?)
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
please send mail to dev-unsubscribe(a)sling to unsubscribe.
Regards
Felix
Will Carpenter schrieb:
> unsubscribe
>
> On Thu, Sep 3, 2009 at 8:55 AM, Joshua Oransky <ca...@gmail.com> wrote:
>
>> unsubscribe
>>
>
>
>
Re: JIRA "needs documentation" state?
Posted by Will Carpenter <ca...@gmail.com>.
unsubscribe
On Thu, Sep 3, 2009 at 8:55 AM, Joshua Oransky <ca...@gmail.com> wrote:
> unsubscribe
>
--
willcarpenterdesign.com
Re: JIRA "needs documentation" state?
Posted by Joshua Oransky <ca...@gmail.com>.
unsubscribe
Re: JIRA "needs documentation" state?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Bertrand Delacretaz schrieb:
> Hi,
>
> On Thu, Sep 3, 2009 at 1:12 PM, Felix Meschberger<fm...@gmail.com> wrote:
>> Bertrand Delacretaz schrieb:
>>> ...I'd suggest three new states then
>>>
>>> "Needs documentation/tests"
>>> "Needs documentation"
>>> "Needs tests"
>>>
>> ...Should these steps be mandatory, thus no close without transitioning
>> through these steps ? Or optional, thuss being able to forget about it...
>
> Optional..keep things simple, and some issues (like fixing a bug)
> don't need docs and tests should be written/updated when fixing the
> issue anyway.
>
>> ...What do we want to capture with the workflow (current states in
>> parentheses) ?
>>
>> * issue has been reported (open)
>> * work is in progress (in progress)
>> * considered fixed (resolved)
>> * confirmed fixed (closed)
>> * requires documentation (-)
>> * requires test case(s) (-)
>> * included in the release (-)...
>
> Can't we use the JIRA "fix version" field to manage that?
>
>> ...Which of these states are allowed and how should transitions be allowed
>> ? E.g. should a transition from open to "included in release" be allowed ?...
>
> I'd leave everything allowed for now, we're a small enough team to
> manage edge cases manually IMHO.
You are probably right and the presence of the optional steps on the
left hand side "menu" might help to not forget about testing/documentation.
Regards
Felix
Re: JIRA "needs documentation" state?
Posted by Bertrand Delacretaz <bd...@gmail.com>.
Hi,
On Thu, Sep 3, 2009 at 1:12 PM, Felix Meschberger<fm...@gmail.com> wrote:
> Bertrand Delacretaz schrieb:
>> ...I'd suggest three new states then
>>
>> "Needs documentation/tests"
>> "Needs documentation"
>> "Needs tests"
>>
> ...Should these steps be mandatory, thus no close without transitioning
> through these steps ? Or optional, thuss being able to forget about it...
Optional..keep things simple, and some issues (like fixing a bug)
don't need docs and tests should be written/updated when fixing the
issue anyway.
> ...What do we want to capture with the workflow (current states in
> parentheses) ?
>
> * issue has been reported (open)
> * work is in progress (in progress)
> * considered fixed (resolved)
> * confirmed fixed (closed)
> * requires documentation (-)
> * requires test case(s) (-)
> * included in the release (-)...
Can't we use the JIRA "fix version" field to manage that?
> ...Which of these states are allowed and how should transitions be allowed
> ? E.g. should a transition from open to "included in release" be allowed ?...
I'd leave everything allowed for now, we're a small enough team to
manage edge cases manually IMHO.
-Bertrand
Re: JIRA "needs documentation" state?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Bertrand Delacretaz schrieb:
> Hi,
>
> On Thu, Sep 3, 2009 at 10:22 AM, Jukka Zitting<ju...@gmail.com> wrote:
>> On Thu, Sep 3, 2009 at 10:12 AM, Bertrand
>> Delacretaz<bd...@apache.org> wrote:
>>> ...does JIRA allow for "needs documentation" (and maybe "needs
>>> automated tests") states for such issues, where the coding is done but
>>> docs and/or tests are still missing.
>>>
>> ...It's possible to specify a custom Jira workflow for something like
>> this. Just define the extra issue states you need and the permitted
>> transitions between the states. The default states used currently are:
>> Open, In Progress, Reopened, Resolved, Closed....
>
> I'd suggest three new states then
>
> "Needs documentation/tests"
> "Needs documentation"
> "Needs tests"
>
> Transition from any state to these would be allowed, and these can
> transition to any state except "Open".
>
> What do people think?
Basically, +1.
Should these steps be mandatory, thus no close without transitioning
through these steps ? Or optional, thuss being able to forget about it
What do we want to capture with the workflow (current states in
parentheses) ?
* issue has been reported (open)
* work is in progress (in progress)
* considered fixed (resolved)
* confirmed fixed (closed)
* requires documentation (-)
* requires test case(s) (-)
* included in the release (-)
* closed (closed)
Which of these states are allowed and how should transitions be allowed
? E.g. should a transition from open to "included in release" be allowed ?
Regards
Felix
Re: JIRA "needs documentation" state?
Posted by Bertrand Delacretaz <bd...@gmail.com>.
Hi,
On Thu, Sep 3, 2009 at 10:22 AM, Jukka Zitting<ju...@gmail.com> wrote:
> On Thu, Sep 3, 2009 at 10:12 AM, Bertrand
> Delacretaz<bd...@apache.org> wrote:
>> ...does JIRA allow for "needs documentation" (and maybe "needs
>> automated tests") states for such issues, where the coding is done but
>> docs and/or tests are still missing.
>>
> ...It's possible to specify a custom Jira workflow for something like
> this. Just define the extra issue states you need and the permitted
> transitions between the states. The default states used currently are:
> Open, In Progress, Reopened, Resolved, Closed....
I'd suggest three new states then
"Needs documentation/tests"
"Needs documentation"
"Needs tests"
Transition from any state to these would be allowed, and these can
transition to any state except "Open".
What do people think?
-Bertrand
Re: JIRA "needs documentation" state?
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Sep 3, 2009 at 10:12 AM, Bertrand
Delacretaz<bd...@apache.org> wrote:
> I have reopened https://issues.apache.org/jira/browse/SLING-922 to
> remind us to document this feature.
>
> We could also create another issue ("document SLING-922") for that -
> or does JIRA allow for "needs documentation" (and maybe "needs
> automated tests") states for such issues, where the coding is done but
> docs and/or tests are still missing.
>
> Does anyone know? If not I'll try to find out how JIRA could help manage this.
It's possible to specify a custom Jira workflow for something like
this. Just define the extra issue states you need and the permitted
transitions between the states. The default states used currently are:
Open, In Progress, Reopened, Resolved, Closed.
BR,
Jukka Zitting