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.
