OFBiz development and high level stories/requirements WAS: Re: squareFootage with decimals

[Jacopo Cappellato <ja...@gmail.com>]

I would like to keep this conversation alive because I think it is an important one.
What do you think about the idea of creating and maintaining stories (*) that have to be referenced in commit logs (ideally each and every commit log should be associated to a story; the same story can be associated to several commit logs) as a way to focus the attention of the community around requirements behind commits?
I think it would be a valuable approach to enable the community interaction around requirements (instead of implementation as it is happening now) with the final goal of:
1) documenting the high level requirements (stories) available implemented by screens and artifacts in OFBiz
2) facilitate the participation in the growth of OFBiz of less technical contributors (e.g. analysts)

Jacopo

(*) An example of story could be the following one:
"Sales Orders are approved automatically when paid by credit card and CC authorization is successful.
Sales Orders are placed in Pending status approval after checkout then auto-approve once third-party payment processor (PayPal, GoogleCheckout, etc) sends notification.
Sales Orders are placed in Rejected status when authorization fails.
Once order is approved inventory is automatically reserved, reducing Available To Promise (ATP) quantity. If inventory is not available negative inventory reservations are created and the order is placed on back-order."

Company sends confirmation email to the Placing Customer."
On Apr 8, 2010, at 2:34 PM, Jacopo Cappellato wrote:

> This is an interesting comment. What we can d to improve this?
> Here is a suggestion: from now on each and every commit to trunk will have to contain the reference to a (short) story that describes the context (i.e. generic business process) that the commit is enhancing.
> This doesn't mean that there will be a story for each commit since several commits will share the same story; over time we will create a good set of stories and it will be easier, when a new story is added, to verify if it represents an alternative/redundant feature etc...
> At the beginning there will be some overhead on the shoulders of committers, but if we are good at keeping the stories consistent this would also help the participation to non-tech guys.
> The stories could stay in Confluence or (maybe better) in Jira (easier to associate commits to Jira tasks).
> 
> Jacopo
> 
> 
> On Apr 8, 2010, at 12:50 AM, David E Jones wrote:
> 
>> 
>> This may or may not help this conversation, but to be clear I no longer believe in the vision of a developer friendly community. Some good things certainly come from the model of community over code and developers being the most important part of a community, but my opinion these days is that e problems trump the benefits.
>> 
>> In an effort where there is a clear design with a written and accepted specification this model seems to work fine. However when the project is not simply implementing an established design what ensues is nothing short of chaos and fighting over design with no clear targets or requirements to help people make decisions.
>> 
>> In short that is why I don't believe in this model for OFBiz. We have problems with designs and not so much with implementation. Most of the problems in the project are due to bad design (or no design other than whatever the code happens to do) and no amount of good implementation can fix that. With testing efforts this will only become more pronounced. Testing efforts will reveal the lack of designs more and more,and while writing tests some functionality gaps will certainly be filled in, but the mind set of testing that includes trying all possibilities will result in enormous scope creep to add to the already staggering amount of unused code. Actually I'm wrong in using the term scope creep because that would imply that some sort of scope had been established before.
>> 
>> I mentioned some stuff about a better approach, or better priorities, in another email where I wrote a little about the NUMMI car plant as an interesting example of a possibly better way to go. Maybe it was silly to think it would ever work well this way and you can't get around prioritizing users over developers and code quality and good design over developers.
>> 
>> -David
>>