Next focus: PROCESS

[foobar]

On Wednesday, 19 December 2012 at 21:58:12 UTC, foobar wrote:
> On Wednesday, 19 December 2012 at 21:30:44 UTC, Andrei 
> Alexandrescu wrote:
>> On 12/19/12 4:23 PM, foobar wrote:
>>> On Wednesday, 19 December 2012 at 20:51:57 UTC, deadalnix 
>>> wrote:
>>>> On Wednesday, 19 December 2012 at 19:56:47 UTC, Rob T wrote:
>>>>
>>>>> Do we all agree that we need a "stable" branch?
>>>>>
>>>>
>>>> No. Stable isn't a boolean criteria. You'll find different 
>>>> degree of
>>>> stability going from not so stable (dev version) to very 
>>>> stable (dead
>>>> project).
>>>>
>>>> The wiki already mention a process with a branch per version 
>>>> of the
>>>> software.
>>>
>>> Let's generalize this point for the sake of reaching 
>>> consensus - we need
>>> _at least one_ "stable" branch which is separate from 
>>> "staging". We are
>>> still conflicted as to what should be the maximum amount. For 
>>> the
>>> record, I'm with the camp advocating at most a fixed amount 
>>> countable on
>>> one hand. That's an O(1) with a very small constant as 
>>> opposed to the
>>> O(n) suggestion by Andrei. I hope Andrei appreciates the 
>>> order of
>>> efficiency here.
>>
>> I agree with one "stable" branch.
>>
>> Andrei
>
> That's great!
> What about the other high level points summarized eloquently by 
> H. S. Teoh?
> Any other high level points or goals the process should 
> incorporate?
>
> 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.
>
> ** 5. After many cycles spanning years, the community accepts 
> that the feature will never be added despite a consensus and 
> constant demand.
> 5.1 Feature is added by surprise with deviations from consensus 
> design, optionally integrates purely with other parts of the 
> language.
> 5.1.1 Feature is final!
>
> Another prime example is the auto-ref feature which we are 
> stuck with because Walter apparently understood differently 
> from what you intended.
>
> This is highly coupled with Walter, making it very hard to 
> agree on a high level design and delegate its implementation to 
> other developers. As far as I see, No major feature was ever 
> implemented by someone other than Walter and he has final say 
> on all design decisions.
>
> I agree with Walter's motives, he wants to stabilize the 
> language and by resisting to feature suggestions he sets a very 
> high bar for any major change. That is a good thing. The 
> problem is that it all happens in his head and not in plain 
> sight. The community has no idea what his plans are, I'm not 
> convinced that even you get all the details. That means no 
> planning ahead and no delegation. Had we known that Walter sign 
> off featureX but just doesn't have the time to implement it, 
> than it still would be on the official *binding* todo list and 
> someone else would be able to implement this feature. As the 
> situation now stands, no one will bother doing any significant 
> work if it has a high chance of being entirely dismissed by 
> Walter.

The high-level steps as I see them:
1. The community discusses the merits and costs of the suggested 
feature and a consensus must be reached regarding adding such a 
feature.
2. An initial design must be provided - also with consensus. 
including this parts:
2.a. Suggested semantics of the feature - describe as precisely 
as possible
2.b. All interactions with other language features must be 
carefully examined and listed.
2.c An initial syntax agreed upon by the community.
3. Feature is implemented and after reaching some agreed upon 
level of stability is than field tested by the public.
3.1 Based on public feedback, feature design can be refined and 
bugs are fixed until consensus is reached that feature is ready 
to be finalized and merged to the next stable release.

It's vague on purpose - the exact details of how each point above 
is approved is to be decided later. The main principle is that 
approved planned features should be listed on the road map and 
point to their DIP with description of their design. Rejected 
features are also listed as DIPs with the rationale for the 
rejection, this is to avoid wasting time on repeat discussing 
them and requesting them.
Ultimate goal for all this is making the planning process as 
transparent as possible for the community.