Next focus: PROCESS

[foobar]

On Thursday, 20 December 2012 at 05:33:27 UTC, Rob T wrote:
> On Wednesday, 19 December 2012 at 21:58:12 UTC, foobar wrote:
>>
>> Personally, I think the whole pre-development stage needs to 
>> get looks at -
>> Specifically having some sort of at least high-level *binding* 
>> planning - road map, mile stones, todo lists. This should give 
>> more weight to DIPs.
>> DIPs at the moment have no weight whatsoever. The attributes 
>> showed all the major flows in the decision making process:
>>
>> 1. Feature idea comes up in discussion.
>> 2. Feature was discussed heavily by the community reaching 
>> some design consensus.
>> 3. Plan is abandoned/forgotten due to Walter's objections - 
>> not to the design but the idea itself.
>> 4. Feature comes up again in discussion, thus returning to 
>> point 1 above in infinite loop.
>>
>
> A big fix is in order there too, it's actually what should be 
> fixed first but from what I've seen going on in here if we can 
> get something even basic implemented for the development and 
> releases that will be a *huge* step forward. Once we have some 
> kind of formalized process in place and prove to everyone how 
> much better things are because of it, it'll be a first by the 
> looks of things, and from that experience the other big holes 
> will become easier to pick out and deal with.
>
> I think we have to keep it simple for now, focus on a dev, 
> staging, release process, implement something, work out the 
> bugs, get people used to having it, and prove the value, then 
> we can get on with tackling the other major issues in a similar 
> way.
>
> There's lots of room for improvement ahead, but we need to make 
> at least one significant step forward in a successful way 
> before we can hope to move on to the next one.
>
> --rt

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.