2009/2/19 Edgar J. De Cleene edgardec2001@yahoo.com.ar:

On 2/19/09 8:47 AM, "Bert Freudenberg" bert@freudenbergs.de wrote:

...

As of late last year I'm not working full-time on Etoys development anymore (now on other Viewpoints Research projects). I'm still contributing of course, and in particular would like to see get Etoys and Squeak.org get closer together again, working together on a common base for all Squeak-based project seems like an obviously good idea to me.

• Bert -

The reunification of forks should be first priority. We need a common base (Pavel morphic core), with clear 4.0 status. And this should load any actual and future Squeak.

No Squeakmap, no Universes, no Installer. A modified CodeLoader, in the image as long as 1999, is enough. A small .cs could be done and applied to all forks.

NO Traits. They found the light !

Who think Morphic is a waste of time and claim they need do business, use Vista

Who think we don't have VisualWorks solid, pay the same as VisualWorks ask and we do.

Edgar, to my sense, you are in contradiction to yourself: - first you saying that we should focus on reunification - second you saying that we should throw away every bit of progress since 1999

Or end to JustTalk and begin to Smalltalk

Edgar, Advocatus Diaboli and Defensor del Pueblo

On 2/19/09 9:59 AM, "Igor Stasenko" siguctua@gmail.com wrote:

An Installer is exactly the tool which focused on reunification of forks (i think Keith repeated this statement multiple times while describing LPF here on mailing list and on wiki). And you want to throw it away..

Ja, I know you also have good sense of humor

I wonder how we could reach 3.10 without Installer...

Edgar

On 2/21/09 7:13 AM, "Igor Stasenko" siguctua@gmail.com wrote:

and then reached 3.10.1, and then 3.10.2 because you reached 3.10 with many critical bugs and ignoring fixes waiting in mantis.

Where you when Ralph put the process of 3.10 ? I not remember your name as any of "Ferrari workers"..

I found your comment totally unfair and kind of you are reading the paper of tomorrow for judge me..

Read the long port to Board list, please.

Edgar

Igor said:

What i really want to point out, that release process were not fair to others, when there only single person deciding whether put fix/feature into release or not.

I have to disagree with you here, although I can see how this is perceived and comes down as always to a communication break down. The fixes applied to each release did not generally come from out of thin air. They originated as reports on bugs.squeak.org, generally from someone other than the harvester. So immediately you have the opinion of at least one other person in support of harvesting the fix/enh. And I think if you look through the list of issues harvested for 3.10 you will find that in most cases weeks or even months went by when everyone had an opportunity to review and comment on submitted fixes. In many cases this did happen. I would really really like for it to happen more.

Of course mistakes were still made. I made more than a few myself. I think you will even find issues where I made the report and harvested it myself without any additional comment.

In support of 3.11 I have to say the situation is slightly better here because Keith and I have worked together to come up with a solution that clearly marks which issues are targeted for each release and the current status. The initial impetus here was purely technical, a way for the build system to automatically harvest issues. But it serves as well to flag issues that concerned Squeakizens (Squeak citizens, yes I know I should have resisted) should pay particular attention to.

Andreas' instructions

http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-February/134095....

may help clarify.

Ken

Overall I agree that the community needs to be further engaged but I'm not sure I understand how your suggestion of BPPs can be effective. I'm going to one-up your strawman by arguing with your particular example, feel free to posit another if appropriate:

Why would someone wanting to do a project agree to this framework? It seems to me if I saw some need I would much rather pursue it freely at my own schedule, be able to fail in something approximating privacy if it comes to that, and not be bound to answer to others. If I then come up with something that I think the community should consider adopting I would present it as something close to a finished project that can be examined and evaluated directly, in contrast to a proposal. Any voting or arbitration or decree by the Leadership can happen just as well at that phase as before. If I'm voted down then I and my compatriots have perhaps lost something (not much really, package it and let anyone who chooses to use it do so individually) but it seems like no greater risk to the community than if the team agrees to a BPP then fails.

Ken

On Sat, 2009-02-21 at 12:45 -0800, Andreas Raab wrote:

Indeed. Which comes back to my reasons for running in this board election. Historically, decisions have been made by the people screaming the loudest or the longest. We need to work out a way to fix this and to come to a process by which we can make decisions that are acceptable to the community at large. Here is a straw-man of what I'm thinking about:

I would like to introduce the idea of a "board project" which is a community project that is approved by the board. The idea is that the board would bless a particular project with a particular schedule and for the period of the project its members can commit freely to the required repositories.

A Board Project Proposal (BPP) would have to include:

• A Rationale: Why would we want this project?
• A Deliverable: What is being done (specifically; best with links to

existing code)

• A Project Lead: Who owns this project?
• A Board Liaison: Who is the board representative for this project?
• A Schedule: What is to be done when.

The most important part of a BPP is its schedule. It allows the board to measure progress by seeing if milestones have been reached. For many things the schedule might be as simple as reserving one month to make the core changes, and another one for bug fixing. That is fine. But what the schedule avoids is having projects stalling forever and nobody knowing how much behind they are and whether it's even still alive.

Anyone can write a BPP and submit it to the board. The board will vote (by closed ballot) on the proposal and can either approve, reject, or ask for revision of the proposal.

If approved, the project becomes active. The members working on the project can freely post to the required repositories. The board tracks and communicates the progress of the active projects in its meetings based on the schedule and the milestones.

If an active project does not reach its milestones, it can be canceled by the board. When a project is canceled it is the responsibility of the board liaison to clean up any damage that might have been created by premature commits.

Here is an example BPP:

---

BPP: Replace InputSensor/EventSensor

1. Rationale: InputSensor/EventSensor are fraught with peril. Many

projects (including Sophie, Hydra etc) have had to fight with its shortcomings. This project is the integration of a rewrite of both of these classes done in Sophie.

2. Deliverable: Integrate code originally posted at

http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg03413.htm...

3. Project Lead: Michael Rueger

4. Board Liaison: Igor Stasenko

5. Schedule:

   • March 09: Update Mantis with code+Installer scripts
   • Milestone: April 1st; All code is committed.
   • April 09: Bug fixing as needed.
   • Project completion: May 1st.

---

With a proposal like the above the board can most definitely vote on it. It's clear what is to be done, why it should be done. There is a schedule that can be used to measure progress. If the milestones are not achieved the board can react properly.

What do people think? I think one of its main advantages is that it strengthens the position of the board. If you don't like what the board's approving, run for it yourself (and yes, there is still time!).

Cheers,

• Andreas

OK, actually the more I wrote the more I began to sense that might be the case. But that still brings me back to the question: Why would the project proposers want to do this?

I think this is an easy sell to the consumers, the Squeakers who are the potential users and beneficiaries of a project. More information earlier is always a good thing. But how is this sold to the producers, the ones doing the work? What is the upside for them?

Ken

On Sat, 2009-02-21 at 13:34 -0800, Andreas Raab wrote:

Hi Ken -

Sorry for being unclear. I absolutely agree with your point about people doing their projects until they feel it's ready. As a matter of fact I think that pretty much all BPPs should be about stuff that's ready to go (see my example which already pointed to the code). I do not want empty upfront commitments; I want to be able to have the board make decisions about concrete work that is there and available to look at.

Cheers,

• Andreas

I think BPPs, is quite sensible way to improve current situation. A developer getting a kind of blessing/approval from board , and he also having a degree of confidence that his work will be adopted in a future release. This would make him better motivated to finish the work and deliver it. As Ken mentioned, for most projects , especially standalone ones BPP is not very useful. But for refactorings / improvements in release image/VM i think it is.

I know at least one project, which cries for integration for a while (more that 2 years?) - Rio.

2009/2/22 Andreas Raab andreas.raab@gmx.de:

What it does is that it gives people a process to work with. You will get a yes/no answer within a bounded time frame. The commitments that come with an approval are clear. You know what the expectations are. Etc.

Remember my main goal here is to re-enable the ability for people to contribute both small and large. If you think the current situation is fine as it is, this proposal may not be for you. It is for people who don't think the current situation is desirable.

There are almost certainly other ways by which to achieve the goal. I have simply formulated one that I think could work. If you have alternative ideas, I'm all for hearing them. My main goals for the process were to:

• have a decision point, a yes/no answer,
• have a schedule that can be tracked externally,
• have clarity about who has commit rights to what,
• have a way of getting out of it when things turn bad.

As long as these points are addressed I'm pretty much good with whatever.

Cheers,

• Andreas

Ken Causey wrote:

...

OK, actually the more I wrote the more I began to sense that might be the case. But that still brings me back to the question: Why would the project proposers want to do this?

I think this is an easy sell to the consumers, the Squeakers who are the potential users and beneficiaries of a project. More information earlier is always a good thing. But how is this sold to the producers, the ones doing the work? What is the upside for them?

Ken

On Sat, 2009-02-21 at 13:34 -0800, Andreas Raab wrote:

...

Hi Ken -

Sorry for being unclear. I absolutely agree with your point about people doing their projects until they feel it's ready. As a matter of fact I think that pretty much all BPPs should be about stuff that's ready to go (see my example which already pointed to the code). I do not want empty upfront commitments; I want to be able to have the board make decisions about concrete work that is there and available to look at.

Cheers,

• Andreas

Hi Andreas,

On Sat, Feb 21, 2009 at 12:45 PM, Andreas Raab andreas.raab@gmx.de wrote:

Igor Stasenko wrote:

...

Now, if we add the nonacceptance of 3.9 release from some of us (traits), maybe its worth considering about changing the release process, otherwise any future release will be doomed to have same level of nonacceptance as previouse releases...

Indeed. Which comes back to my reasons for running in this board election. Historically, decisions have been made by the people screaming the loudest or the longest. We need to work out a way to fix this and to come to a process by which we can make decisions that are acceptable to the community at large. Here is a straw-man of what I'm thinking about:

I would like to introduce the idea of a "board project" which is a community project that is approved by the board. The idea is that the board would bless a particular project with a particular schedule and for the period of the project its members can commit freely to the required repositories.

A Board Project Proposal (BPP) would have to include:

• A Rationale: Why would we want this project?
• A Deliverable: What is being done (specifically; best with links to

existing code)

• A Project Lead: Who owns this project?
• A Board Liaison: Who is the board representative for this project?
• A Schedule: What is to be done when.

The most important part of a BPP is its schedule. It allows the board to measure progress by seeing if milestones have been reached. For many things the schedule might be as simple as reserving one month to make the core changes, and another one for bug fixing. That is fine. But what the schedule avoids is having projects stalling forever and nobody knowing how much behind they are and whether it's even still alive.

Anyone can write a BPP and submit it to the board. The board will vote (by closed ballot) on the proposal and can either approve, reject, or ask for revision of the proposal.

If approved, the project becomes active. The members working on the project can freely post to the required repositories. The board tracks and communicates the progress of the active projects in its meetings based on the schedule and the milestones.

If an active project does not reach its milestones, it can be canceled by the board. When a project is canceled it is the responsibility of the board liaison to clean up any damage that might have been created by premature commits.

Here is an example BPP:

---

BPP: Replace InputSensor/EventSensor

1. Rationale: InputSensor/EventSensor are fraught with peril. Many projects

(including Sophie, Hydra etc) have had to fight with its shortcomings. This project is the integration of a rewrite of both of these classes done in Sophie.

2. Deliverable: Integrate code originally posted at

http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg03413.htm...

3. Project Lead: Michael Rueger

4. Board Liaison: Igor Stasenko

5. Schedule:

• March 09: Update Mantis with code+Installer scripts
• Milestone: April 1st; All code is committed.
• April 09: Bug fixing as needed.
• Project completion: May 1st.

---

With a proposal like the above the board can most definitely vote on it. It's clear what is to be done, why it should be done. There is a schedule that can be used to measure progress. If the milestones are not achieved the board can react properly.

What do people think? I think one of its main advantages is that it strengthens the position of the board. If you don't like what the board's approving, run for it yourself (and yes, there is still time!).

I think this is an excellent idea but completely pointless unless this process is one that comes to the attention of community members quickly and easily. Here's what I suspect; I could just be projecting my own initial experience, but I suspect it is more widely shared. I suspect that many community members, newbies and oldies alike, don't realise there is a community process because the various introductory web portals focus, understandably, on getting a Squeak system into the hands of the user, not on community process. So the newbie becomes an oldie without being made aware of the community structure around their use of Squeak. To them the community process appears to be mysterious and a little cliqueish. Hence they may feel excluded, ignorant and hence unhappy. This may lead to them screaming long and loud in an effort to get what they want because they have not been informed of how to participate in community process effectively, if at all.

So I suggest you augment the above with a significant effort to extend the existing web portals with visible and enticing links to content that explains community structure and process and extends a welcome hand to encourage them to participate. If the community doesn't effectively publish its process, no matter how open it may be in reality, it will be perceived as being closed and exclusive.

I imagine verbiage to the effect of

"Squeak is a vibrant and expanding open-source community with many members. It has great ways to participate, in existying projects, in fixing bugs, in exploring blue-sky and in evolving the system both as a platform and as the future of computing. Here's (i.e. some link) a great overview of the community. Even if you're not ready to get involved now you probably will some time soon; this is a great place to be. So if not now, please remember this and visit the overview some time when you're interested in getting more involved."

would be suitably welcoming. But text to this effect needs to be front and centre, not hidden off side pages. Further, the overview needs to be well-written, well-structured, concise, informative and up-to-date. If we put effort into this I think there will be significant benefits, in rates and degrees of involvement, in reduction of conflict, and in enabling a more effective debate about evolving community structure and process. In short more happy lads and lasses and more Squeak.

Cheers,

• Andreas

Hi guys!

Just wanted to chip in and mention two things:

1. There is a web team led by Janko with Igor as advisor. It has a mailinglist: webteam@lists.squeakfoundation.org But of course you know that, just mentioning it for those who may be aware. :)

2. The discussion about what should be on the "front page" is an ongoing theme in the web team. We have changed it, changed it and... changed it again. :)

The current style is not so uninviting as you may suggest below IMHO - the second headline is called "Take Part in the Innovation". And there are multiple links there, like:

Join the community to find common interests. Participate in the teams.

...so even though I ALSO think a welcoming text very early on would be beneficial, it is not like we are hiding stuff away.

I on the other hand think the Team model and how it was meant to work from the beginning is something that I very much would like to hear more thoughts about and what the candidates think about it.

regards, Göran

Craig Latta wrote:

...

When a project is canceled it is the responsibility of the board liaison to clean up any damage that might have been created by premature commits.

 Hmm, that could be quite difficult in practice. Why put that 

responsibility on the liaison, rather than the people most familiar with the code?

Well, if they are around and willing to do, yes, absolutely. The main reason for putting the responsibility with the liaison is that at the point where a project goes south the contributors might no longer be available (temporarily or permanently). Plus, there can be situations where you may want to keep certain things and not others - if that happens I want the responsibility to lie with the liaison to decide what stays and what must go. Finally, I want it to be clear for the liaison that there can be real work involved if they decide to take on a project.

Cheers, - Andreas

I'm not sure I voted before. Do I need to be registered?

On 19 Feb 2009, at 02:47, Bert Freudenberg bert@freudenbergs.de wrote:

On 19.02.2009, at 10:18, Göran Krampe wrote:

...

Hi all!

This is a reminder that if you are going to announce that you are running for the Squeak Leadership team 2009, you should announce your candidacy now. There are only 3 more days before the nomination period ends on 22nd of February.

We currently have 10 nominations for 7 seats on the board (that's much better than last year where we only had 5 with 4 days left). They are:

Jecel Assumpcao Jr Ken Causey Edgar J. De Cleene Matthew Fulmer Craig Latta David Mitchell Brent Pinkney Andreas Raab Randal L. Schwartz Igor Stasenko

regards, Göran, Election leader

Please put my name down again, too. It's too great a lineup to miss out on :)

As of late last year I'm not working full-time on Etoys development anymore (now on other Viewpoints Research projects). I'm still contributing of course, and in particular would like to see get Etoys and Squeak.org get closer together again, working together on a common base for all Squeak-based project seems like an obviously good idea to me.

• Bert -

I asked the same question this morning before I saw Göran's post - what's he doing posting messages at 1am? :-) Makes me want to move to Europe so I can get ahead of the sleepy west coast...

The URL is here http://wiki.squeak.org/squeak/6116

Steve

On Thu, Feb 19, 2009 at 9:43 AM, Gonzalo Romano gonzalo.romano@gmail.comwrote:

I want to vote but I'm not registered I Know you've already talked about this but is just now I have the time to write ... I've been working with squeak since 2006 with little things, and since past september started working on a real project, i was registered as an apprentice in squeak people...

well can't actually talk abot what i do but i'd like to vote :D

-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

At Thu, 19 Feb 2009 11:47:47 -0600, Ken Causey wrote:

You are already registered. As a base the voting list starts with last year's voting list built up over the years on SqueakPeople. The voting list from SqueakPeople is all SqueakPeople accounts with at least Apprentice status. That includes you and I have confirmed that you are on the list with this email address. You will receive a voting invitation.

Just looking at the wiki page, it wasn't clear to me that when the voter list will be finalized/closed. I'd imagine the case where somebody assumes he is on the list but isn't and notice it after March 1st. (Or simply notice this is going on after March 1st.)

Is the plan to allow such new voters between 1st and 8th also?

-- Yoshiki

Hi Göran,

In the past we closed the list but we allowed people that did not have access to their email to get a new ballot. We verified that the first ballot bounced by contacting the voting site administrator and asking them to forward bounces to us. If the original email bounced we sent a new one to the requested address and asked people to update their squeak people account (which won't work now).

We did not allow new people to sign up after the deadline, which was when we pulled the list of voters.

Ron Teitelbaum

-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Göran Krampe Sent: Sunday, February 22, 2009 7:29 AM To: The general-purpose Squeak developers list Subject: Re: [squeak-dev] [Election] I want to vote

Yoshiki Ohshima wrote:

...

Just looking at the wiki page, it wasn't clear to me that when the voter list will be finalized/closed. I'd imagine the case where somebody assumes he is on the list but isn't and notice it after March 1st. (Or simply notice this is going on after March 1st.)

Is the plan to allow such new voters between 1st and 8th also?

Good question. Technically it would not be a problem - but I am not sure about the other aspects - any views? Off the top of my head I don't remember how we did that last year.

regards, Göran