RE: [Proposal] Issue Driven Development (IDD)
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:[email protected]] Sent: mardi 14 novembre 2006 09:03 To: '[email protected]' 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
Does this mean that if an issue is already closed we don't need to create a new one ? We should reopen it ? Or create a sub-task ? Ludovic Vincent Massol a écrit :
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:[email protected]] Sent: mardi 14 novembre 2006 09:03 To: '[email protected]' 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
------------------------------------------------------------------------
-- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
-- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic
-----Original Message----- From: Ludovic Dubost [mailto:[email protected]] Sent: mercredi 15 novembre 2006 13:07 To: [email protected] Subject: Re: [xwiki-dev] RE: [Proposal] Issue Driven Development (IDD)
Does this mean that if an issue is already closed we don't need to create a new one ?
Yes, that's correct, provided the issue was created in the same version as the fix/modification you're bringing.
We should reopen it ? Or create a sub-task ?
Neither. You should look at it from the point of view of release notes. It wouldn't make sense to have something like: Release notes for XWiki 10.5: * [XWIKI-11002] Implement new Gizmo feature * [XWIKI-11003] Fix bug for new Gizmo feature That's at least the strategy I've been using in the past. -Vincent
Vincent Massol a écrit :
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:[email protected]] Sent: mardi 14 novembre 2006 09:03 To: '[email protected]' 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
---------------------------------------------------------------------
______________________________________________________________________ -
--
-- You receive this message as a subscriber of the xwiki- [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
-- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic
___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
Yes, I totally agree. We were doing this at a moment, but we stop. On 11/14/06, Vincent Massol <[email protected]> wrote:
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:[email protected]] Sent: mardi 14 novembre 2006 09:03 To: '[email protected]' 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
-- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
-- jeremi
participants (3)
-
jeremi joslin -
Ludovic Dubost -
Vincent Massol