I'll try to do a karma grant for Rave folks tomorrow, meaning you can all start committing to your hearts content :-)
Upayavira On Fri, 25 Mar 2011 16:32 +0000, "Ross Gardler" <[email protected]> wrote: > On 25/03/2011 15:07, Scott Wilson wrote: > > > > On 25 Mar 2011, at 14:48, Franklin, Matthew B. wrote: > >> It looks like accounts for us new committers are being created. As > >> we prepare to commit the donated code bases, I thought it would be > >> good to lay out some of the next steps. The last few weeks seem to > >> have been busy for everyone, and we haven't had many discussions > >> regarding what we need to do to get Rave moving forward. The > >> following is a list of things I think we need to accomplish in the > >> near term. The list is by no means comprehensive and there is > >> probably a better place for it to live, but it is intended to spark > >> discussion. > > > > Looks like a good start - thanks for starting the ball rolling! > > > >> 1. Commit donated code bases 2. Finish public website on CMS (think > >> Ross started this?) > > Not yet. It's getting closer to the top of my todo list. now you are All > getting your logins I will keep it moving up. My intention is to put a > skeleton in place for you and you can take it from there. > > >> 4. Discuss working agreements for coding practices, quality, unit > >> testing, coverage, CI, sandbox environments, etc (Some of this is > >> probably standard Apache practice) > > > > I don't think there is such a thing as a standard Apache coding > > practice :-) > > Scott is correct. There is no "standard" but there are a whole bunch of > common practices that you'll find here. I'm not sure how the other > mentors plan to tackle this issue. My own style is to let you get on > with it and pipe up if I believe either a) something is potentially > harmful to an ASF project or b) there is a way to do something that I > believe will help. > > For your mentors to do this effectively you need to discuss everything > here on the list. I don't think there will be much of a problem with > that in these team. > > >> 7. Agree on process for "cherry picking" features and > >> integrating them into the Rave code base > > > > Well, we can pick things we want to work on and mail the list to say > > we're doing it, but beyond that I don't think we can have that much > > of a process - anyone can implement any features they want and submit > > patches for them, its up to committers whether to commit them. > > Yes, this is probably the best approach. > > 1) say I'm going to work on getting feature X implemented I know how the > code in foo does that so I'm going to use that as a starting point. This > means I will implement it like this [pseudo code/UML/whatever] > > 2) community sits back and lets it happen or shouts "no - bar does it > better because.." > > 3) regular, frequent and early commits to give people chance to sound a > word of caution early > > One of the approaches I like in some of our projects is for someone to > post a "Random Thought". This is a very early stage proposal for a > solution. The fact that it is a Random Thought means that people know it > is not supposed to be fully thought out and so constructive criticism > and enhancements are welcome. > > These are posed to the list with [RT] in the subject and will typically > define a use case, a problem preventing the use case from being carried > out today, a rough idea that will satisfy the use case, a rough proposal > for how it might be implemented > > Often such an RT can start the above 1-2-3 cycle going. > > Ross >
