Independent of the current discussion, this is a nice description of how the current process works. Should be made into an FAQ item somewhere.

- Bert -

On 09.05.2011, at 16:23, Nicolas Cellier wrote:

> 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