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 > > > On Apr 6, 2010, at 3:29 AM, Jacopo Cappellato > <jacopo.cappell...@hotwaxmedia.com> wrote: > >> >> On Apr 3, 2010, at 6:59 PM, Ean Schuessler wrote: >> >>> I have a friend who's favorite business saying is "start out where you want >>> to end up". It is sort of a nonsense phrase but it says something similar >>> to "a stitch in time saves none". If we are clear about what we are trying >>> to build it will be much easier to put those fixes in now than to try to >>> change course down the road. >>> >>> In my mind, we are trying to do something revolutionary which is to bring >>> the power of ERP down to the small to medium size business player. Its >>> revolutionary because, if successful, it has the potential to change the >>> dynamics of business and the structure of the world economy. If we are >>> going to succeed in that task we are really forced to confront the reality >>> of what those business owners need. That means providing business >>> continuity even in the face of small budgets and a minimal IT staff. >> >> Agreed. But the main point that is often ignored is that we are doing this >> revolution with *minimal* resources: a limited group of active committers >> and a small group of service providers. >> The only way we can win is to understand our limits and be clever and study >> new (unconventional) ways of achieving our goals. >> This was done in the past of OFBiz, mostly thanks to David's vision >> (developer friendly community, push to use the trunk to maximize feedback >> and contributions etc...). >> >>> If we can make the "myth" of easy upgrades a reality then our software it >>> going to be much more widely adopted. >>> >>> I'm not trying to brush the complexity of this under the rug. I agree with >>> you whole-heartedly that seamless upgrade-in-place is probably a real pain >>> for us to achieve. At the same time, it also has the possibility to reduce >>> our overall workload. >>> Adam and I personally have to oversee upgrading customer installations on a >>> regular basis and those upgrades are typically time consuming and a little >>> bit scary. If this problem was reduced to literally pushing a button it >>> would free up time that could be spent on more productive tasks that >>> actually improve the customer's business. >> >> I understand your pain, but this is not a good enough motivation for moving >> the burden of backward compatibility on the community shoulders; I know that >> this is not what you meant but the true reality is that the issues you have >> faced with upgrades were not even strong enough to induce you or Adam (that >> are in the restricted group of the most generous contributors) to contribute >> back upgrade scripts etc... so I don't expect they will be a strong >> motivation for others. Enforcing a rule is not enough. We have to find >> better ways of inducing the community to help with backward compatibility. >> And one way is the one I have suggested: invite companies or service >> providers that are in the process of upgrading an OFBiz instance to discuss >> the process in the list and to cotribute back their experiences, scripts >> etc... others will benefit from this and may also help. This is very >> different from expecting the "upgrade button" to ba made available by >> committers. This is more in line with the effort of building a community of >> people interested in upgrades and willing to help, contribute and >> participate. >> >> Jacopo >> >>> >>> My $0.02. >>> >>> ----- "Jacopo Cappellato" wrote: >>>> In rev. 930182 I have created also the upgrade script to migrate data from >>>> old to new fields. >>>> By the way, are we sure it is a good idea for the project to enforce these >>>> rules about backward compatibility? >>>> It seems to me that the development in OFBiz is becoming more difficult >>>> every day and this is self evident from this small improvement that has >>>> caused a rather long thread. >>>> We are worried about causing harm to an hypothetical group of end users >>>> that, we suppose, don't follow the dev lists, don't have any internal IT >>>> team that can help them in the migration, don't have a budget for the >>>> upgrade, don't understand about the risks of upgrading a production ERP >>>> instance and just want to do this by blindly pressing a button. >>>> We are sacrificing the very limited time of our brave committers against >>>> this "myth". In my opinion we just went too far, the risk is that we go >>>> into the mud and slow down because this plan is not compatible with the >>>> resources of our community. There is also the risk that we are trying to >>>> fix a problem that is not there: chances are that the silent end users >>>> have very good budgets, very skilled IT teams that have greatly customized >>>> their OFBiz and simple just want to take care of the critical system >>>> upgrade on their own. >>>> So I would like to propose a change in our 'policies' to switch from >>>> "backward compatibility" to "backward awareness" based on the following >>>> principles: >>>> 1) committers are encouraged to improve existing code, clean it up, >>>> improve data model etc... even if the changes could cause some problems >>>> during upgrade; OFBiz has to grow efficiently in the best way possible >>>> considering the limited group of contributors >>>> 2) however, since we know that there are companies that are willing to >>>> stay up to date with the OFBiz growth but don't want to invest resources >>>> in the upgrade process or staying in synch with the community, then we >>>> will do our best to simplify the upgrade path; this means that, if time >>>> permits, committers are encouraged to apply the deprecation patterns (for >>>> bigger and more critical changes), or at least write some notes to warn >>>> people about the change occurred that could impact an upgrade etc... >>>> 3) we should also send the message out (from our site, mailing lists etc) >>>> to the silent end users that, if they are in the process of upgrading from >>>> an older release they should at least mention this in the user list: in >>>> this way the community will have a chance to provide suggestions, warn >>>> about potential issues, etc and most of all this will help the community >>>> of end users to test together and cooperate on upgrade scripts >>>> What do you think? >>>> Jacopo >>> -- >>> Ean Schuessler, CTO Brainfood.com >>> e...@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315 >>
