[squeak-dev] Resolution of Contentious Issues

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Mon May 9 19:23:50 UTC 2011


I see, you would want to introduce more democracy in the development process.
This raises many questions:
- Who would have the power to raise the subject to be voted for
- Who would formulate the questions
- Who could vote
- Should vote be motivated or not

By now, the situation is the following (my understanding):

The core developpers have commit right.
They shall do peer reviews on commits.
The core developpers are nominated by the board.
The board is elected by a community.
The community members are co-opted.

Design decisions are discussed in squeak-dev.
Anyone can participate to the dicussion.
The final commit decision is in the hand of core developpers.
Until now, decisions are generally discussed before applied (apart
obvious fixes).
They are rather motivated and meet agreement among the peers
(at least, they meet no major disagreement).

Anyone can submit a change in the inbox.
There is no guaranty that this change will be integrated or even considered
As mentionned earlier, the fastest way to integration is a good rationale.
The biggest the change is, the best the rationale should be.

Anyone can submit an idea in squeak-dev.
However, please consider that an idea might be far from a solution.
You'll probably have to convince both programmers and commiters, and
make plans...

As stated in an old thread, trunk has no global development plan.
Trunk is just a community of individuals with individual goals.
This configuration favours a certain conservatism.
This is seen as an advantage for maintaining existing applications.
Introduction of pragmatic little changes is rather fast and welcomed in trunk.
Generally, the trunk is not doing bad wrt continuous integration.

On the other side, introduction of major changes certainly is restrained.
IMO, integration of major changes can happen if these changes:
- are ready to integrate
- either simplify a framework or extend functionalities significantly
- don't gratuitously ruin compatibility with a bunch of usefull packages
- are elegant, simple, not over-engineered

I think Pharo is somehow complementary:
less conservatism and less restrictions about API changes.
Pharo has written goals (and certainly some unwritten too) and
priorities (kind of plan).
So if you have revolutionary solutions matching one of the goals
(written or unwritten), you might knock at Pharo's door.
However, neither is Pharo a democracy.

If you have a wonderful simplification, you can also try selling it to
Juan and have it adopted in Cuis.
Neither a democracy.

Well, having a choice among several dictatorships already is a start
of democracy ;)
That said, current model is not written in stone and can evolve.
It should evolve if it fails to find resources to survive.
IMO the board should drive these evolutions.
Anyone can ask for though and you're welcome.

Nicolas

2011/5/9 Stéphane Rollandin <lecteur at zogotounga.net>:
> My opinion on this is:
>
> If a problem is hairy and people disagree on options, discussing it at
> lengths in big threads that may repeat what has already been said, it means
> that a lot of work is needed to understand the issue from all its relevant
> dimensions; involved people, the one who write posts about it, have specific
> point of views and if no agreement can be reached, it is because it is
> difficult to grok the point of view of someone else, or to explain
> convincingly why it is maybe not an interesting point of view.
>
> Anyway. The last thing I would like in such a situation is a community vote.
> Because a vote does not explain anything, a vote does not tell if the voter
> understand anything whatsoever about the problem being discussed, a vote
> does not give any clue about the voter motivation and involvement. The vote
> does not bring anything constructive, so why bother ?
>
>
> my 2 cents,
>
> Stef
>
>



More information about the Squeak-dev mailing list