On Thursday, 20 December 2012 at 08:27:22 UTC, foobar wrote:
I see both as going hand-in-hand, otherwise we have chicken-egg problem. We need a better process to allow more developers to contribute code more easily *and* we need better planning to provide incentive for new developer to contribute code. Implementing only the the planning provides incentive but no means. Implementing only the process provides the means but not the incentive.

While improving git mastery levels is beneficial of itself, it brings no benefit to the _users_ if only Walter is still the main developer. We end up wasting Walter's time on adjusting to a new system for a hypothetical non existent system of many developers, when he already has a working system for the actual existing situation of being the sole main developer.

We need an *initial high-level* design for both parts. We can define and refine the details later and we probably should defer it to later and adjust it as we go along based on experience. Arguing now on the exact time span of a release just wastes mind cycles and detracts from the important bits - reaching a consensus regarding the goals of the project and defining a general workflow that achieves those goals with minimal amount of overhead.

I think what was proposed - to fast track this one, and not over engineer - is a good idea. That way we can at least get something that's far better than before, and be able to more quickly move on to the next big problem area which I would agree is what you are mentioning. There's lack of planning and how decisions are made is very inefficient and arbitrary, and I would also say we have a big problem with the specification being poorly managed, eg, it's not even available for download, has no process for revisions and releases, nothing at all - it's worse than the existing development process which we all agree is in need of a big overhaul.

Please, let's all agree to deal with that monster next, but it's a big problem to solve, and if we try to bundle it in with this one, we may not get any accomplished at all. I'd prefer the divide and conquer approach.

--rt

Reply via email to