[Proposal] Issue Driven Development (IDD)

Vincent Massol vincent at massol.net
Tue Nov 14 10:03:45 CET 2006


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 at massol.net]
> Sent: mardi 14 novembre 2006 09:03
> To: 'xwiki-dev at 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




More information about the devs mailing list