Or even informal roles. For example: My employer doesn't use eCommerce, so I am not qualified to be responsible for that. But, I will gladly take on responsibility for areas of the project my employer uses - like Work Effort and Asset Maintenance.
I have been thinking about that lately - each contributor or committer could list the areas they feel comfortable with overseeing. It would be strictly voluntary - not a serious commitment or anything. The reason I suggest it is because I recognize my own limitations - I can't review and comment on EVERYTHING. I have a feeling other committers are in the same situation. So, why not catalog our strengths, and assume responsibility for pieces of the project we feel confident with - instead of (right or wrong) feeling responsible for the whole project. W could use the service provider Wiki page as a model - create a Wiki page where everyone advertises what areas of the project they feel knowledgeable in. -Adrian --- On Mon, 2/15/10, Christopher Snow <[email protected]> wrote: > From: Christopher Snow <[email protected]> > Subject: Re: Rethinking our release strategy > To: [email protected] > Date: Monday, February 15, 2010, 10:16 PM > As part of the release plan, could we > create some formal roles responsible for certain aspects for > each release? i.e. people responsible for: > > - migration from previous release > - documentation > - patch management > - etc > > > David E Jones wrote: > > A release plan would be great. How are we going to do > that, or what would it look like? > > > > -David > > > > > > On Feb 15, 2010, at 1:20 PM, Sharan-F wrote: > > > > > >> Hi > >> It sounds like there 's some confusion as to > whether the release branches > >> are being updated with bug fixes or not. I thought > they were. > >> > >> My focus has been pretty much been on OFBiz > documentation and I find it > >> very, very hard to document things as they are > changing so fast. Features > >> seemed to be added with no hint of documentation > or even a spec. The only > >> way to find out how things work, is trial > and error and not everyone is > >> interested in (or capable of) looking at or > understanding the code. > >> Personally I'd like to see a yearly release plan > so that we could at least > >> ensure that we had enough time to make it truly > stable and that the right > >> documentation is in place to support the release. > >> > >> Thanks > >> Sharan > >> > >> -- View this message in context: > >> http://n4.nabble.com/Rethinking-our-release-strategy-tp1555976p1556580.html > >> Sent from the OFBiz - Dev mailing list archive at > Nabble.com. > >> > > > > > >
