What I am considering is the following: Sending a detailed proposal with analysis of the problem and a statement of the options to this list, followed by a seperate call for alternate suggestions. I'd split it, since a part of me is not looking forward to a messy back-and-forth email-based discussion where the full proposal is quoted full. I'd probably suggest pasting the proposal into a Wiki page and have only discussion about the proposal in the mailing list? If I maintain the wiki page based on mailing list discussions (with appropriate feature labelling), then interested parties can follow the discussion and only have to load the wiki page (no login required) for full context.
Once consensus has been achieved (after voting, or whatever method is deemed appropriate), the revised statement document can be posted to the mailing list.. Developing in a branch is probably a good idea, especially as it can alter (significantly) existing core behaviour. Regards, Kevin On 18 Oct 2010 at 9:44, Robert Matthews wrote: > Another option, particularly where an idea is to be explored, is to > create a branch and do some initial work within that. It's easy for > other to see what's really required and is then easy to merge into the > trunk when ready. > > In fact, any code that changes the API, particularly in Core should > consider this approach, so that others working from the trunk are not > continually disrupted while small changes trick through - this allows > for one update that requires changes. > > Regards > Rob >
