Hi,
I've noticed that the xwiki jira is using the default resolved step. In most
of the jira I have managed I have removed this step as it's seldom or never
used and leads to issues being resolved but never closed... BTW I've noticed
that our JIRA has 56 issues resolved but not closed... :-) I'm pretty sure
they should be closed.
Here's my proposal: remove the resolved state. I can do it.
If an issue is closed but still has problems then the reporter can reopen
it.
Here's my +1
Thanks
-Vincent
___________________________________________________________________________
D�couvrez une nouvelle fa�on d'obtenir des r�ponses � toutes vos questions !
Profitez des connaissances, des opinions et des exp�riences des internautes sur Yahoo! Questions/R�ponses
http://fr.answers.yahoo.com
Here are some additional tips to qualify my post below:
* In you want to know whether you should create a jira issue or not ask
yourself the question: "is my change going to affect any user or any plugin
developer"? If the answer is yes then you must create a jira issue
* You shouldn't create a bug issue for a new feature that you or someone
else has implemented in the current version under development. Whatever fix
you do must be against the existing JIRA issue for that bug/feature.
The idea here is that the changelog must be as meaningful as possible.
Thanks
-Vincent
> -----Original Message-----
> From: Vincent Massol [mailto:vincent@massol.net]
> Sent: mardi 14 novembre 2006 09:03
> To: 'xwiki-dev(a)objectweb.org'
> Subject: [Proposal] Issue Driven Development (IDD)
>
> Hi XWiki committers,
>
> I'd like to suggest one good practice when developing with JIRA:
> whenever someone commits something to SVN he/she has to put the
> reference to the JIRA issue # in the commit message. Of course this
> shouldn't be done for any trivial things like adding a small javadoc,
> renaming a single variable, cosmetic changes, svn ignore, etc.
>
> The strategy goes like this:
>
> * When you plan to work on something, create a jira issue and assign it
> to yourself
> * Implement it
> * Commit it with the jira issue #
> * Close the jira issue
>
> Another acceptable variation is:
>
> * Implement something
> * When you want to commit it you realize you don't have any jira issue
> to put in the commit message so don't commit
> * Create the jira issue
> * Commit
>
> The rationale behind this:
>
> * One consistent way to manage our work (this is different from now
> where sometimes it's in jira and sometimes it's not). It also means
> there's no unaccounted work, meaning I can go to jira and query it and
> I'll see what everyone has been working on.
> * Automated release notes/change logs. When we release a version we can
> simply do a jira extract and it'll give the full change log of what
> happened. This is really important for our users to see what has been
> done when in XWiki.
> * Tracability. When you use the jira issue # in your commit, the jira
> subversion plugin can show the modified files directly from jira. This
> is quite useful later on, when someone is looking at a jira issue and
> wants to see what was modified. In addition fisheye is also integrated
> with jira and when you browse the source repository you can see the
> jira issue associated with files.
>
> I'm proposing that we adopt this practice in XWiki.
>
> WDYT?
>
> Thanks
> -Vincent
>
> PS: Some time back I blogged about 6 jira issue smells. This was one of
> them. Here's the link: http://tinyurl.com/yzv4bf
___________________________________________________________________________
D�couvrez une nouvelle fa�on d'obtenir des r�ponses � toutes vos questions !
Profitez des connaissances, des opinions et des exp�riences des internautes sur Yahoo! Questions/R�ponses
http://fr.answers.yahoo.com
