Juan Vuletich wrote:

The Team model failed. We don't have enough knowledgeable people with available time to donate to cover all parts of Squeak.

The Board is the only way we have to make decisions. I propose giving the Board complete rights to make any decision. When taking important decisions the Board might decide to ask the Assembly to vote. The Assembly is made of core contributors to Squeak. Only the Board and core contributors have influence on the decisions. This will help to keep Squeak following its objectives, and will make it likely there will be people to actually put into practice the decisions made. We still need a reasonable way to identify core contributors, though.

What do you think?

I'm with you on this. I want a strong board, a board that can and does make decisions, a board that correct its course of action where necessary. I think the terms of reference should state explicitly that:

* the board is ultimately responsible for ensuring ongoing development and timely releases of Squeak * the board is responsible for creating an environment in which the community can contribute code and otherwise participate * the board can delegate its responsibilities to members of the community (teams) to take care of whatever needs to be done

There are some parts that are quite reasonable but I think it needs to be stated clearly that "the buck stops here" i.e., with the board. It is our assumed duty as shepherds of the community to make sure that development goes on. It is our duty to make sure releases happen. It is our duty to ensure Squeak is present and visible. We can delegate some or all of it (and do so where we can because all of us are doing this in our spare time) but it doesn't release us from the responsibility, and implies guidance and oversight on the board's behalf.

The good news here is that because of we have elections every year it's quite easy to change things - run for the board. If you feel that a significant part or direction in the community is underrepresented, please run! Make your voice heard, that's what the elections are for.

Cheers, - Andreas

I don't want to start a flame but so will end. Anyway...

From some weeks to date I have been wondering what is the point of so

many little and not so little random fixes going to trunk (not minimizing the effort or quality of them, that they indeed have). I have entered the Squeak page and nowhere could I find a single sentence about the goals that motivated so may changes.

Are they trying to fix Monticello (fix what)? Are they trying to fix input (unicode, japanese, russian, what?)? Are they trying to fix collections (were they broken?)? Are they trying to get some social results by experimenting with the number of automated mails about said fixes and reactions of people?

This are some of the headers of the 524 (in my inbox) mails sent automatically for each single commit to the squeak trunk.

[squeak-dev] The Trunk: Tools-bf.106.mcz [aug 20, 2009] [squeak-dev] The Trunk: MonticelloConfigurations-edc.60.mcz [aug 21, 2009] [squeak-dev] The Trunk: MonticelloConfigurations-ar.61.mcz [aug 21, 2009] ... [squeak-dev] The Trunk: Monticello-ul.331.mcz [oct 05, 2009]

Some could say that they show that are a lot of work (because are a lot of commits) but you could also say that they are part of just two or three single goals (e.g Fixing monticello and fixing collections) although with each single goal implemented as 200 commits, all part of the same overall change. That way it doesn't look as much work being done.

I tried to look in the squeak page for a list of goals or milestones that the individual commits are trying to fix and couldn't find any. So I can't get the overall picture. The squeak list is full of commits mails that for a new user say nothing. On the other side, the page is the same old outdated page with no hints about where the squeak is going on.

What is a new user to learn about this? Or to expect about squeak in a give timeframe?

Then is the issue of the blog vs. list discussions. Igor, has posted a terms of reference request for discussion in the blog, not in the list. This touch a point that Keith put in the table four or five months ago and nobody wanted to discuss in the moment? Has something changed now that the topic is worth discussing? The meat of the discussion is the role of the board. And that is something that I can't understand because four months ago the de facto solution was to give the board time to organize and later, they promised, they will show the road to follow. But I don't see that today. Today we are in the same point that before, without established responsibilities/limits and without a published road for squeak. Too bad.

The squeak oversigth blog list the agendas for each meeting:

11/18/2009 Free server hosting options Terms of Reference Packaging/Distribution of Contributed Packages with Release SFC/Relicensing Promotion and Visibility of Squeak Development Progress Squeak Swiki Improvement Comment with any suggestions.

11/4/2009 Terms of Reference Free Server Hosting Options SFC/Relicensing Promotion and Visibility of Squeak Development Progress Squeak Swiki Improvement

10/21/2009 Should we be paying attention to something? Let us know… Community Server/Services Hosting SFC/Relicensing Promotion and Visibility of Squeak Development Progress The technical responsibilities of the Board Squeak Swiki Improvement

10/7/2009 SFC/Relicensing Promotion and Visibility of Squeak – OOPSLA, ECOOP? Internal Processes Development Progress The technical responsibilities of the Board Squeak Swiki Improvement

9/16/2009 SFC/Relicensing Promotion and Visibility of Squeak Internal Processes Development Progress The technical responsibilities of the Board Squeak Swiki Improvement

9/2/2009 Internal Processes Development Progress Relicensing Progress The technical responsibilities of the Board Squeak Swiki Improvement

8/19/2009 Suggestions are appreciated. Development Progress Relicensing Progress The technical responsibilities of the Board

8/5/2009 Development Progress Relicensing Progress The technical responsibilities of the Board Squeak Swiki upgrade/replacement

7/15/2009 Development Model Progress Relicensing Release Progress

7/1/2009 3.11 Status 4.0/Relicensing Status Squeak Swiki update or replacement Teams

5/7/2009 Project Updates Licensing Status Mission Statement Teams Updates Process improvements

4/17/2009 Project Updates Seconds (aka backups) Licensing Release Mission Statement Teams Positioning towards other communities Process improvements (BPPs, decision making etc)

And so and so...

Do you see the trend? Discussions and discussions from at least april 2009 and nothing that a external unknowing user could say about the future of squeak.

Summary, squeak has no direction and we are not better now than 6 months ago.

So finally, the question?

Where is Squeak going?

As said, I don't want a flame but it is really disappointing to see this community getting lost in the color of the bikeshed.

http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAIN...

Board, do one thing: Make decisions not discussions.

Put a list of goals move the boat that way.

Cheers

On 11/5/09 4:27 PM, "Igor Stasenko" siguctua@gmail.com wrote:

As for Keith's proposals: first time i heard about them not long ago in IRC chat, and i reacted.

Ha ha ha.

Good joke ! Only Board member and qualified Squeaker who don't know ?

I don't agree with Keith 98% of the time, but you can't said he don't try to discuss about the release process and how he think Squeak should be made.

Edgar

Edgar J. De Cleene wrote:

On 11/5/09 4:27 PM, Igor Stasenko wrote:

...

As for Keith's proposals: first time i heard about them not long ago in IRC chat, and i reacted.

Ha ha ha.

Good joke ! Only Board member and qualified Squeaker who don't know ?

I don't agree with Keith 98% of the time, but you can't said he don't try to discuss about the release process and how he think Squeak should be made.

By "Keith's proposals" Igor meant the set of rules Keith suggested for the board and teams recently on IRC, which Igor then brought to the board for discussion and we have brought to squeak-dev. Igor was not aware of previous attempts to define such rules even though Miguel said this discussion was many months old. For one attempt to start this discussion, see my post from February -

http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-February/134 288.html

-- Jecel

The crux of the problem that the Terms of Reference discussion has been initiated to solve, in my opinion is:

1. The release team had previously clearly outlined the path forward and this path was apparently approved by the board: Refer to: http://installer.pbworks.com/SqueakReleaseTeam http://installer.pbworks.com/Squeak311 http://installer.pbworks.com/Squeak311Proposal http://installer.pbworks.com/Squeak311Proposal

2. Somebody in their great wisdom got excited at a certain point that there had been no release for some time, even tho it had been clearly documented and approved that 3.11 was not about a release per se, but mostly about improving the tools and process. Then the board dictatorially instituted the new development model, saying deceptively that the new development model was just an experiment. There was no discussion with the current release team, there was no attempt made to help understand and improve the existing tools and process, there was no attempt made to work with the release team going forward. And there was no attempt made to bring the desires of the board to the release team in order to improve any perceived shortfall of the release team. The board's thoughtless actions resulted in the total sidelining and destruction of the previous significant progress made towards improving tools and process for the benefit of all of the Squeak community, work done mainly by Keith.

In my mind, the actions by the board were in this case totally unacceptable and there is a great need to institute some binding rules (Terms of Reference) to ensure this sort of thing never happens again.

There still is no clearly communicated vision of the path forward via the new development model.

How will this new development model be merged and integrated with the previously clearly communicated and board approved release path? How does the new development model benefit the Squeak community as a whole, including the various forks? How does the new development model improve the methodology for maintaining external packages such as Monticello? How the the new development model improve the methodology for modularizing and removing sections of code that can preferentially be maintained as externally loadable and unloadable packages?

Ken G. Brown

At 11:13 AM -0600 11/5/09, Miguel Enrique Cobá Martinez apparently wrote:

I don't want to start a flame but so will end. Anyway...

...

From some weeks to date I have been wondering what is the point of so

many little and not so little random fixes going to trunk (not minimizing the effort or quality of them, that they indeed have). I have entered the Squeak page and nowhere could I find a single sentence about the goals that motivated so may changes.

Are they trying to fix Monticello (fix what)? Are they trying to fix input (unicode, japanese, russian, what?)? Are they trying to fix collections (were they broken?)? Are they trying to get some social results by experimenting with the number of automated mails about said fixes and reactions of people?

This are some of the headers of the 524 (in my inbox) mails sent automatically for each single commit to the squeak trunk.

[squeak-dev] The Trunk: Tools-bf.106.mcz [aug 20, 2009] [squeak-dev] The Trunk: MonticelloConfigurations-edc.60.mcz [aug 21, 2009] [squeak-dev] The Trunk: MonticelloConfigurations-ar.61.mcz [aug 21, 2009] ... [squeak-dev] The Trunk: Monticello-ul.331.mcz [oct 05, 2009]

Some could say that they show that are a lot of work (because are a lot of commits) but you could also say that they are part of just two or three single goals (e.g Fixing monticello and fixing collections) although with each single goal implemented as 200 commits, all part of the same overall change. That way it doesn't look as much work being done.

I tried to look in the squeak page for a list of goals or milestones that the individual commits are trying to fix and couldn't find any. So I can't get the overall picture. The squeak list is full of commits mails that for a new user say nothing. On the other side, the page is the same old outdated page with no hints about where the squeak is going on.

What is a new user to learn about this? Or to expect about squeak in a give timeframe?

Then is the issue of the blog vs. list discussions. Igor, has posted a terms of reference request for discussion in the blog, not in the list. This touch a point that Keith put in the table four or five months ago and nobody wanted to discuss in the moment? Has something changed now that the topic is worth discussing? The meat of the discussion is the role of the board. And that is something that I can't understand because four months ago the de facto solution was to give the board time to organize and later, they promised, they will show the road to follow. But I don't see that today. Today we are in the same point that before, without established responsibilities/limits and without a published road for squeak. Too bad.

The squeak oversigth blog list the agendas for each meeting:

11/18/2009 Free server hosting options Terms of Reference Packaging/Distribution of Contributed Packages with Release SFC/Relicensing Promotion and Visibility of Squeak Development Progress Squeak Swiki Improvement Comment with any suggestions.

11/4/2009 Terms of Reference Free Server Hosting Options SFC/Relicensing Promotion and Visibility of Squeak Development Progress Squeak Swiki Improvement

10/21/2009 Should we be paying attention to something? Let us knowŠ Community Server/Services Hosting SFC/Relicensing Promotion and Visibility of Squeak Development Progress The technical responsibilities of the Board Squeak Swiki Improvement

10/7/2009 SFC/Relicensing Promotion and Visibility of Squeak - OOPSLA, ECOOP? Internal Processes Development Progress The technical responsibilities of the Board Squeak Swiki Improvement

9/16/2009 SFC/Relicensing Promotion and Visibility of Squeak Internal Processes Development Progress The technical responsibilities of the Board Squeak Swiki Improvement

9/2/2009 Internal Processes Development Progress Relicensing Progress The technical responsibilities of the Board Squeak Swiki Improvement

8/19/2009 Suggestions are appreciated. Development Progress Relicensing Progress The technical responsibilities of the Board

8/5/2009 Development Progress Relicensing Progress The technical responsibilities of the Board Squeak Swiki upgrade/replacement

7/15/2009 Development Model Progress Relicensing Release Progress

7/1/2009 3.11 Status 4.0/Relicensing Status Squeak Swiki update or replacement Teams

5/7/2009 Project Updates Licensing Status Mission Statement Teams Updates Process improvements

4/17/2009 Project Updates Seconds (aka backups) Licensing Release Mission Statement Teams Positioning towards other communities Process improvements (BPPs, decision making etc)

And so and so...

Do you see the trend? Discussions and discussions from at least april 2009 and nothing that a external unknowing user could say about the future of squeak.

Summary, squeak has no direction and we are not better now than 6 months ago.

So finally, the question?

Where is Squeak going?

As said, I don't want a flame but it is really disappointing to see this community getting lost in the color of the bikeshed.

http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAIN...

Board, do one thing: Make decisions not discussions.

Put a list of goals move the boat that way.

Cheers

-- Miguel Cobá http://miguel.leugim.com.mx

I pointed out to Keith on IRC a while ago that it was simply impossible for the board to "break the rules" since we have never had any rules. He has kindly suggested a possible set of such rules and I think that is a good starting point for a discussion.

In the page in the blog I have added some links to the rules or organizations of other Free Software projects. Most other project have no rules that I could find and even these are pretty informal.

Given that our community is pretty small, that elections are frequent (every 12 months) and that re-elections are very common (most of the current board was part of the previous one), I don't think most of the proposed rules would help very much. I'll make a brief comment on each one:

1) [board selects team and lets it decide all else]

This wasn't done by the previous board for the web team: one group proposed using Seaside and another Aida such that by picking a team a technical decision was being made indirectly. I think that this will often be the case for future issues as well.

2) and 3) [avoid conflict of interest, board member should follow same rules as everyone else]

This was violated in a big way with the creation of the Trunk repository, where all board members automatically became core developers along with several other people. In general, however, board members have had enough sense of fair play that this hasn't yet been a big problem, in my own opinion (other people might feel very differently).

The problem with these two rules are that it isn't very easy to check that they are being followed since "unfair" is rather subjective. I would rather see this as part of some "declaration of principals" than as a "term of reference", but perhaps there isn't much difference between these.

4) and 5) [how teams and the board should interact]

This is actually how things were done in most cases. The one exception was the Trunk thing (if you consider that a replacement of 3.11 rather than a third effort parallel with the on-going 3.11 and 4.0 ones). So I agree with this one.

6) [no general rules for internal team communication]

Sure.

7) [board delegates all real work to teams]

I interpreted the results of this year's election as a desire for a more "hands on" board that makes technical decisions directly. So I don't think the community would be happy with this rule.

8) [respect decisions from previous board]

Like I said above, most of the current board was also the previous one. They changed their minds about some things and I don't think there should be a rule preventing them from doing so.

9) There should be a grievance procedure and an equal opportunities policy including disability awareness

I didn't attempt to paraphrase this because I didn't understand it.

One thing that Keith mentioned, a "vote of no confidence" followed by an ad hoc election, didn't get included in this list. Without that I don't see what the answer could be to "what happens if the rules get broken?"

Given that the next election is at most 12 months away and that any ad hoc election would probably pick the exact same board that was just kicked out, I am against such a rule. But without it, none of the others "have any teeth".

I would be happy with general principals rather than rules, and the board has previous tried to define that:

http://squeakboard.wordpress.com/our-mission/

-- Jecel