What would we achieve by cataloging the pieces of the project we feel confident with? If it's not a serious commitment then how would it differ from what we do right now, aside from having an extra wiki page?
Regards Scott HotWax Media http://www.hotwaxmedia.com On 16/02/2010, at 12:04 AM, Adrian Crum wrote: > 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. >>>> >>> >>> >> >> > > >
smime.p7s
Description: S/MIME cryptographic signature
