Smalltalk › Squeak › Squeak - Dev

[squeak-dev] [Election] Nomination period ends in 3 days!

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

30 messages Options

Göran Krampe

[squeak-dev] [Election] Nomination period ends in 3 days!

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

Bert Freudenberg

Re: [squeak-dev] [Election] Nomination period ends in 3 days!

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 -

Edgar J. De Cleene

Re: [squeak-dev] [Election] Nomination period ends in 3 days!

On 2/19/09 8:47 AM, "Bert Freudenberg" <[hidden email]> 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.

Or end to JustTalk and begin to Smalltalk

Edgar, Advocatus Diaboli and Defensor del Pueblo

Igor Stasenko

Re: [squeak-dev] [Election] Nomination period ends in 3 days!

2009/2/19 Edgar J. De Cleene <[hidden email]>:

>
>
>
> On 2/19/09 8:47 AM, "Bert Freudenberg" <[hidden email]> 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
>

--
Best regards,
Igor Stasenko AKA sig.

Igor Stasenko

Re: [squeak-dev] [Election] Nomination period ends in 3 days!

2009/2/19 Igor Stasenko <[hidden email]>:

> 2009/2/19 Edgar J. De Cleene <[hidden email]>:
>>
>>
>>
>> On 2/19/09 8:47 AM, "Bert Freudenberg" <[hidden email]> 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
>

sorry for double-posting..

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...

>> Or end to JustTalk and begin to Smalltalk
>>
>> Edgar, Advocatus Diaboli and Defensor del Pueblo
>>
>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

--
Best regards,
Igor Stasenko AKA sig.

Edgar J. De Cleene

Re: [squeak-dev] [Election] Nomination period ends in 3 days!

In reply to this post by Igor Stasenko

On 2/19/09 9:55 AM, "Igor Stasenko" <[hidden email]> wrote:

> - second you saying that we should throw away every bit of progress since 1999

No , I say we should use reliable tools, which could be used without any
package.

Universe is a super thing , thanks to Lex

SqueakMap do a very valuable service all this years

Installer help me to build 3.10 !!!

But at the time Ralph choose me (I wish he back) I don't know CodeLoader
exist.

I have my own Monticello which could load any as pictures, sounds, morphs.
The proof is on SqueakSouce Rompecabezas as old as 2006-11-21

But Ralph say Monticello have his owner and he only modify very few for let
us build 3.10

But one day I joke with Keith about doing Monticello 1.33 1/3 (like the
Naked gun movie) and he took seriously and come with his own Monticello

So we now have countles Monticello .

Also I begin all to move to Monticello 2 from long time and this is not 1999
, right ?

I still own locate the old man speaking Ukranian, so maybe we understand
better.

Edgar

Edgar J. De Cleene

Re: [squeak-dev] [Election] Nomination period ends in 3 days!

In reply to this post by Igor Stasenko

On 2/19/09 9:59 AM, "Igor Stasenko" <[hidden email]> 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

Steve Wart

Re: [squeak-dev] [Election] Nomination period ends in 3 days!

In reply to this post by Bert Freudenberg

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

On 19 Feb 2009, at 02:47, Bert Freudenberg <[hidden email]> 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 -
>
>
>

Gonzalo Romano

[squeak-dev] [Election] I want to vote

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/

Steve Wart

Re: [squeak-dev] [Election] I want to vote

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 <[hidden email]> wrote:

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/

Ken Causey-3

Re: [squeak-dev] [Election] I want to vote

In reply to this post by Gonzalo Romano

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.

Ken

On Thu, 2009-02-19 at 14:43 -0300, Gonzalo Romano wrote:

> 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
>
>
>

signature.asc (196 bytes) Download Attachment

Yoshiki Ohshima-2

Re: [squeak-dev] [Election] I want to vote

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

Igor Stasenko

Re: [squeak-dev] [Election] Nomination period ends in 3 days!

In reply to this post by Edgar J. De Cleene

2009/2/19 Edgar J. De Cleene <[hidden email]>:

>
>
>
> On 2/19/09 9:59 AM, "Igor Stasenko" <[hidden email]> 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...
>

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.
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...

> Edgar
>
>

--
Best regards,
Igor Stasenko AKA sig.

Edgar J. De Cleene

Re: [squeak-dev] [Election] Nomination period ends in 3 days!

On 2/21/09 7:13 AM, "Igor Stasenko" <[hidden email]> 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 Stasenko

Re: [squeak-dev] [Election] Nomination period ends in 3 days!

2009/2/21 Edgar J. De Cleene <[hidden email]>:

>
>
>
> On 2/21/09 7:13 AM, "Igor Stasenko" <[hidden email]> 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..

I do not judging you. 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. This is what i
expect to be changed once we have new 3.11 release process.
And current 3.11 team going towards this - to give much freedom in
adopting fixes/enhancements , or even building own image without deep
knowledge/expertise of it.

>
> Read the long port to Board list, please.
>
i will

> Edgar
>
>
>
>
>
>

--
Best regards,
Igor Stasenko AKA sig.

Ken Causey-3

Reviewing fixes/enhancements (was Re: [squeak-dev] [Election] Nomination period ends in 3 days!)

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.html

may help clarify.

Ken

signature.asc (196 bytes) Download Attachment

Andreas.Raab

[squeak-dev] Board projects (was Re: [Election] Nomination period ends in 3 days!)

In reply to this post by Igor Stasenko

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@.../msg03413.html

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

Ken Causey-3

Re: [squeak-dev] Board projects (was Re: [Election] Nomination period ends in 3 days!)

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@.../msg03413.html
>
>
> 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
>
>

signature.asc (196 bytes) Download Attachment

Eliot Miranda-2

Re: [squeak-dev] Board projects (was Re: [Election] Nomination period ends in 3 days!)

In reply to this post by Andreas.Raab

Hi Andreas,

On Sat, Feb 21, 2009 at 12:45 PM, Andreas Raab <[hidden email]> 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@.../msg03413.html

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

Andreas.Raab

Re: [squeak-dev] Board projects (was Re: [Election] Nomination period ends in 3 days!)

In reply to this post by Ken Causey-3

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

Ken Causey wrote:

> 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@.../msg03413.html
>>
>>
>> 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
>>
>>