[OFBiz] Dev - Jira and Community Involvement [was: Jira 174]

David E. Jones jonesde at ofbiz.org
Sat Apr 16 22:04:00 EDT 2005


Adrian, and others,

Yes, naturally you are correct that skill (or knowledge) is a major  
reason, or rather a major limitation in how much an individual can  
contribute to OFBiz, or anything like OFBiz. Actually, in my opinion  
this is a particularly difficult thing about OFBiz. It only takes a few  
days to cover the basics of the infrastructure or framework and tools  
in OFBiz (getting advanced takes MUCH more time and background  
knowledge, but often isn't necessary for general development or  
customization of business level artifacts, especially newer ones). The  
problem, the biggest problem, is all of the business level stuff. There  
are hundreds of entities and thousands of fields and relationships in  
the data model (which is perhaps the most basic part of the business  
side of OFBiz). There are many hundreds of screens, with more being  
created all the time. There are hundreds of thousands of line of code,  
and it is highly redundant code or anything, it is very compact "code"  
in the form of highly declarative XML files. OFBiz currently does in  
half a million lines of text what most other techniques require at the  
least 1-2 million lines, and perhaps more.

So, yeah, that's difficult to get your head around...

=====================

On the topic of granting more commit access to people: this is done as  
people demonstrate ability and continued involvement. We don't want to  
just arbitrarily grant commit access, that presents HUGE quality  
control issues. Perhaps it wasn't clear in my message, but one of the  
big issues with patches and other contributions is that they come in  
with LOTS of bugs and problems. Even the internationalization patches  
have typically come in with problems, on the order of 100 bugs  
introduced by those patches over the last couple of years since that  
effort started. Some are minor, like bad label names with missing  
characters or that had not been added to the properties files. Some  
were more serious and caused pages to not render properly. Some of  
those were caught when putting in the patches, but we didn't test every  
modified page (and obviously neither had those who did the  
internationalization), and so many come up later, and in fact many are  
still there, I find them every so often and others do too.

I'm not saying there is anything wrong or unique about those who worked  
on the i18n effort. In fact, they have done a GREAT job, and rather  
large one. I just bring it up as an example because it would seem to be  
a relatively simple thing, yet caused many many problems. With other  
contributions the error rates tend to be MUCH higher, and often more  
serious. Even Andy and I with our experience and continual involvement  
with OFBiz introduce bugs that we don't notice in our testing. Or,  
sometimes I must admit that we do notice them and just don't care  
enough at the time because it isn't core to what we are trying to do,  
and often we put comments in about that.

=====================

On the topic of priorities for tasks: Yes, I still agree that 174 is  
something that should be cleaned up and put in. But it is one of many  
hundreds of such things, and so it has to wait its turn.

This relates to the topic of more people with commit privileges.  
However, that isn't a viable solution until more people express  
interest, and demonstrate ability with a number of contributions before  
they get those privileges. So, that's not an option right now. I wish I  
had some way to offer incentives to people with good ability so that  
they would want to participate, but I really don't have much to  
offer...

In spite of that, people with less skills can still review issues and  
patches and offer feedback on them and at the very LEAST help with  
testing. Because that is where much of the time goes when putting in  
patches (and fixing bugs or other issues in them), if someone else  
helped with review it would save time for the person who eventually  
commits it (mostly Jacopo and me right now).

Another thing people can do, even if they can't review and test patches  
or trace down bugs, is to vote for the things they think are the most  
important. At least then we would have some feedback from the  
community, and not just the insistence of one person, about what is  
most important.

So, for everyone who gets involved, and/or is involved, THANK YOU from  
me and everyone else using OFBiz. I say that on behalf of everyone else  
because even if they aren't grateful for it, any use of it implies that  
gratitude is in order.

-David



On Apr 15, 2005, at 8:31 AM, Adrian Crum wrote:

> David,
>
> Thanks for the response!
>
> One more motivation to add to your list of reasons why developers work  
> on certain portions of OFBiz: skill level. There are things I would  
> like to work on in OFBiz, but I'm still not confident I have a  
> thorough understanding of all of it.
>
> For instance, the seed data loader enhancement (Jira 191) is something  
> I would like to tackle, but I won't - because it involves getting  
> deeper into OFBiz than I'm comfortable with.
>
> So, I stick with relatively easy contributions that don't change any  
> processing or delve into Java code. The SecurityData.xml work I did in  
> the past and the UI refactor I'm doing now don't really change any  
> logic - they are just reorganizations of existing files. That's the  
> level of involvement that I'm comfortable with right now.
>
> In addition to the voting, I would like to recommend another way to  
> speed things up: open up SVN commit access to more people. There are  
> very talented developers out there who are responsible enough to be  
> given access. Why not lighten the load on the few who have it now?
>
> Regarding Jira 174 in particular - that work was fueled by several  
> requests in the mailing lists and you saying that it was work that  
> needed to be done, but no one had time to do it. Voting on it would be  
> redundant - users and yourself have already expressed that it's  
> needed.
>
> David E. Jones wrote:
>> This brings up a good issue... prioritizing efforts in OFBiz.
>> Pretty much everyone involved in OFBiz does things on their own time   
>> and decides what they want to work on, or does things on an  
>> employer's  or client's time, and prioritizes the needs and requests  
>> of those "what  pay for da time."
>> I certainly try to handle incoming requests and issues, but at times  
>> it  is simply more than I as an individual can handle. I really  
>> appreciate  the help of Jacopo, and sometimes various others on these  
>> things, but  more is needed...
>> With a tool like Jira we really can have more community involvement,   
>> and it would help a lot! There are dozens of outstanding issues in   
>> Jira, and various other bugs, issues, priorities, etc that are not in  
>>  Jira. For things that aren't in Jira, we should push submissions  
>> there  more, and I plan to start entering the things that I would  
>> like to work  on there, things like:
>> - move to CSS-based layout, especially in ecommerce (partially done,   
>> but quite a bit left to do)
>> - clean up CSS layout and other CSS issues in the manager  
>> applications,  especially the order manager right now
>> - entity extension/override mechanism in Entity Engine entity   
>> definition files (can help with customization and more isolated   
>> components)
>> - conversion of JPublish and JSP/Region pages to use the Screen Widget
>> - a simple but full back to front set of example artifacts in the   
>> example component, plus narrative about what everything means and  
>> what  the development process for creating those artifacts might look  
>> like
>> - address the issue where an un-closed (committed or rolled back)   
>> transaction makes threads bad, and never recovers; need some recovery  
>>  mechanism so that one bad bit of code among the hundreds of events  
>> and  scripts and such won't bring down an entire server
>> - fix bugs and other issues that come up (these constantly do, right   
>> now around 5-10 per week typically)
>> Some of these are necessary to get resolved ASAP, and some are   
>> necessary or at least HIGHLY desirable to get done before the next   
>> binary release.
>> =========== THE KEY:
>> To help with my decisions on priorities for these and other things, I  
>>  would REALLY appreciate community feedback. This helps the project   
>> serve the needs of those who are using it better, and it allows me to  
>>  step out of the position of being that bad guy that tells people who  
>>  have invested effort into something: sorry, I won't review it and  
>> put  it in because in my opinion it is a lower priority than other   
>> outstanding issues.
>> How to help?
>> 1. vote for tasks/issues in Jira that you think are important!
>> 2. review submissions and improvements in Jira and comment on them
>> 3. if you have a pet-peeve or other issue, submit it as a Jira issue   
>> with good detail, and then vote for it
>> This will help those that do the final review and commit to feel more  
>>  comfortable that there are no major issues with the changes and   
>> additions, and if there are issues to get them resolved before the   
>> final review and commit effort begins.
>> If you have an issue that you think is important and no one is  
>> looking  at it, don't ask me or the other commiters to take care of  
>> it, send a  message to the users or dev mailing list and ask people  
>> to review it  and vote for it.
>> There have been various discussions about this over time, and I think  
>>  the project is to the point where not doing things this way is   
>> preventing growth and progress...
>> I'm very interested in hearing feedback on this, and even MORE   
>> interested in seeing feedback and voting going on in Jira.
>> Thanks to everyone for all of your help, including you Adrian. I know  
>>  you have put a lot of effort into this contribution to the project,  
>> and  I wish I had more time to work on such things and facilitate  
>> those  improvements in the project.
>> -David
>> P.S. Once again through pure narcissism I like this post and think it  
>>  is important for everyone working with OFBiz to read, so I have  
>> edited  it and added it to my blog at:
>> https://www.undersunconsulting.com/ofbizdoc/control/MainBlog?  
>> contentContentId=BLOGROOTJONES&currentMenuItemName=BLOGROOTJONES
>> On Apr 14, 2005, at 1:28 PM, Adrian Crum wrote:
>>> Could we start getting some of the patches committed? They're  
>>> starting  to get old enough to cause conflicts with the current SVN.
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> Dev at lists.ofbiz.org
>>> http://lists.ofbiz.org/mailman/listinfo/dev
>> ---------------------------------------------------------------------- 
>> --
>>  _______________________________________________
>> Dev mailing list
>> Dev at lists.ofbiz.org
>> http://lists.ofbiz.org/mailman/listinfo/dev
> _______________________________________________
> Dev mailing list
> Dev at lists.ofbiz.org
> http://lists.ofbiz.org/mailman/listinfo/dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2363 bytes
Desc: not available
Url : http://lists.ofbiz.org/pipermail/dev/attachments/20050416/c6a53e39/smime.bin


More information about the Dev mailing list