[squeak-dev] On the upcoming Leadership Election

Hello squeakers,

A year has been passed and we are now going to elect a new Leadership
team (many of us is still calling it Board ;).

In the light of this event, i want to propose create a list of
requests, issues and proposals which will be addressed to a newly
elected team.
Let us help them with understanding what is the most important issues
we have, and to start not from own to-do list, but also consider YOUR
thoughts.

Please, feel free to add own IMPORTANT topic to the list, share your
plans and vision about the future of Squeak.
I do expect, that at all current team members will react on this and
write down their thoughts.
But it is open to anyone - PLEASE, do not hesitate to write own. I
think as a member of Squeak community YOUR thoughts should be taken
into account.

I will collect all messages and compile them into one list, and then
put this on a plate before new Leadership team :)

Please, send messages to the squeak-dev list, or in private mail to me.


--
Best regards,
Igor Stasenko AKA sig.

I think this is a good idea, although maybe just a little early since
the election itself is a couple of weeks away.  But it may take some
time for ideas to trickle in, so maybe early is better.

This reminded me of the questionnaire presented to candidates in past
leadership elections.  Goran mentioned this in his email and I think it
would be a great idea for someone to take leadership on organizing on of
these for this election; and it has to be some who is not a candidate.

Ken

2009/2/14 Ken Causey <[hidden email]>:
> I think this is a good idea, although maybe just a little early since
> the election itself is a couple of weeks away.  But it may take some
> time for ideas to trickle in, so maybe early is better.
>
> This reminded me of the questionnaire presented to candidates in past
> leadership elections.  Goran mentioned this in his email and I think it
> would be a great idea for someone to take leadership on organizing on of
> these for this election; and it has to be some who is not a candidate.
>

I didn't meant to create a list of questions for candidates, but more
like a list of topics to discuss for a future team.
And not during election but right after election. I want to see, how
many things are sitting there unsolved or any ideas about the future.

If you think i crossing the line here, i will step aside and let
someone else (name yourself!) to do it.

My message was a proposal to open a discussion to summarize what is
done and what is not, and outline a future plans. I think it is
appropriate time to do so before new Leadership election.



--
Best regards,
Igor Stasenko AKA sig.

Ideas to improve Squeak
Make Squeak callable by other programs. Make Squeak well behaved in plugin or addon environments. It would be so much easier to make Squeak financially viable by selling small plugins or addons, rather than complete applications. I see this in the areas of 2D and 3D CAD. Squeak cannot possibly win on looks, so let it do great work hidden.

All the best,
Aik-Siong Koh

Igor,

I did not mean to imply that you are soliciting questions for a
candidate questionaire.  These are two separate but conceptually related
ideas:

1.  A list of issues that the community would like the Leadership team
to consider.  This is completely appopriate for anyone inside or outside
of the Leadership team to compile and organize.  You suggested this and
I'm fine with the idea.

2.  A questionnaire for Leadership team candidates to aid voters in
their decision in the upcoming election.  This is nothing new, we have
done it in the past, and your solicitation simply reminded me of it.
I'm now reminding the community of it and asking that someone put one
together and I think that it would be inappropriate for a candidate to
be involved.

Ken

On Sat, 2009-02-14 at 05:44 +0200, Igor Stasenko wrote:

This is a perfect example of something I think the Leadership team
should NOT have anything to do with.  The Leadership team should
concentrate on those issues where a single decision has to be made or a
job should only be done once.  For example joining the Software Freedom
Conservancy can only be done once, there is no value in competition
here.

On the other hand technical issues can be investigated and solved by
anyone and competition, if any, only improves the situation for
everyone.  I'm certainly not opposed to the Leadership team smoothing
the way somehow, but I currently see nothing it could do on this issue.
I suppose it's conceivable that some day we might end up with two
competing solutions and no easy way to decide.  In that case it might be
appropriate for the Leadership team to step in and arbitrate.  But I
find it extremely hard to believe that the community itself could not
make a decision.

Let me be clear, if this is the sort of thing you expect the Leadership
team to focus on, do not vote for me.  Outside of the Leadership team I
would contribute to a solution to this problem as I could and cheer
right along with everyone else, but just as another developer and
community member, not as a Leadership team member.

Ken

On Fri, 2009-02-13 at 20:33 -0800, askoh wrote:
> Ideas to improve Squeak
> Make Squeak callable by other programs. Make Squeak well behaved in plugin
> or addon environments. It would be so much easier to make Squeak financially
> viable by selling small plugins or addons, rather than complete
> applications. I see this in the areas of 2D and 3D CAD. Squeak cannot
> possibly win on looks, so let it do great work hidden.
>
> All the best,
> Aik-Siong Koh

On Feb 13, 2009, at 9:18 PM, Igor Stasenko wrote:


1) Make it as easy to run a Squeak application from a command prompt  
or terminal window as GNU Smalltalk.
2) Add support for native threads and utilizing multiple cores/
processors.
3) Either put significant effort into a replacement for Morphic or  
document Morphic much better. I've pretty much given up figuring out  
even basic things like discovering all the out-of-the-box widgets and  
learning the best ways to lay them out in containers.
4) Make Squeak a happier place with much less fighting between  
subgroups.

---
Mark Volkmann
http://www.ociweb.com/mark

2009/2/14 Ken Causey <[hidden email]>:
Ken, i will make a separate list of technical-related questions.
Squeak is not only an idea, a philosophy, but a software environment
which stays behind ideas and works.
We weren't been here if this wasn't true.

--
Best regards,
Igor Stasenko AKA sig.

A simple+powerful GUI designer which runs accross multiple Squeak releases  
(and does not depend on other packages).

It should provide concepts+vocabulary from HTML+DOM+CSS+bindings so that  
even noobs feel comfortable and don't immediately run away as soon as they  
confront morphic.

And in the tradition of Smalltalk, the morphic implementation details have  
to be "encapsulated away", leaving it to experts to squeeze the maximum  
out of morphic.


On Sat, 14 Feb 2009 23:10:18 +0100, Mark Volkmann wrote:

--
"If at first, the idea is not absurd, then there is no hope for it".  
Albert Einstein

So far i've collected 5 messages..
Hey, wake up! We need more! :)

--
Best regards,
Igor Stasenko AKA sig.

OK

How about setting up some standard or even informal mechanisms to help keep the several forks of Squeak in sync where appropriate?

Steve

Igor Stasenko wrote:
> So far i've collected 5 messages..
> Hey, wake up! We need more! :)

You're right. After some careful consideration I've decided to throw my
hat in the ring as well. Count me in.

I'm doing this with a clear agenda: I want to (re-)enable a process by
which contributions flow into Squeak, both small and large. From my
point of view somewhere along the way we've lost the ability to pick up
contributions, to continually improve Squeak. Except from small bug
fixes and enhancements there is no process by which we can decide
whether a particular contribution should be included, whether a
particular turn in the development of Squeak should be taken, whether a
change is worth the risk that comes with it.

We are not a benevolent dictatorship. We will have to find other means
of making such decisions. However, finding a way to make such decisions
is absolutely critical if we want to progress. Right now there is a
variety of improvements out there that nobody has looked at simply
because there is no process for making decisions. Examples include
Freetype rendering, Hydra, Rio, Nile, Gstreamer support, Polymorph,
Omnibrowser, but also things like Databases (SqueakDBX, ODBC), or even
Seaside, Aida etc. There are questions about minimalistic Morphic,
FunSqueak, Etoys etc. All of these should be open for discussion, some
of them will end up being external packages, others may end up being
bundled (via Universes or similar mechanisms) and yet others may go
straight into the release image.

All of the above exist. These aren't projects that someone will only
start if given assurances about their outcome. Rather than making
wish-lists about projects that nobody is working on, I'd like to see
more requests for the integration of work that has been done already.
This is the kind of stuff where the board can decide on, assign a
liaison to ensure integration and get things done that way.

Similarly, Keith and Ken are building some fantastic tools for getting
stuff out of Mantis. Why not build a network of trust for people who can
add candidates to the next Squeak version which is rooted at the board?
In other words, if you have been blessed by any of the board members,
you could add your fix straight to the next alpha build.

The above are all examples of things we can try. I'm not saying any of
those is the right solution but I am asking for a mandate in trying to
establish a process that will allow us to continually improve Squeak.

Cheers,
   - Andreas

On Wed, 18 Feb 2009 05:50:18 +0100, Steve Wart wrote:

> OK
>
> How about setting up some standard or even informal mechanisms to help  
> keep the several forks of Squeak in sync where appropriate?

You may want to check two related initiatives,

- http://www.google.com/search?q=sport+smalltalk+dialects+squeak

and

-  
http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-December/123298.html

both can/do address some of the forks.

--
"If at first, the idea is not absurd, then there is no hope for it".  
Albert Einstein

+1.

2009/2/18 Andreas Raab <[hidden email]>:


--
Germán S. Arduino
http://www.arsol.biz
http://www.arsol.net

On 2/18/09 3:02 AM, "Andreas Raab" <[hidden email]> wrote:
I can't add other as sharing all Andreas views.

And count me on the next race to Board.
I having a awful 2009 start, full of unexpected troubles as my iMac PPC
finally bite the dust.

But I still think Squeak is the only Open Source project deserving all my
energy.

I plan to see some of my far away in colleagues in Brest this year, so take
your turn to beat me :=)

Edgar

On Tue, 2009-02-17 at 21:02 -0800, Andreas Raab wrote:
> Igor Stasenko wrote:
> > So far i've collected 5 messages..
> > Hey, wake up! We need more! :)
>
> You're right. After some careful consideration I've decided to throw my
> hat in the ring as well. Count me in.

Excellent, thank you Andreas.

> Similarly, Keith and Ken are building some fantastic tools for getting
> stuff out of Mantis.

Just a clarification on this.  Keith is primarily building the tools.
I'm primarily being an annoyance but as I am the Mantis 'maintainer'
Keith has had to get my cooperation to the extent that he needs changes
to our Mantis installation.  As a result I sometimes know more about
what is going on than many, doesn't necessarily mean I'm responsible for
much of the result.

Matthew Fulmer is more formally involved in this but has most recently
been asked to turn his attention to the relicensing and 4.0 work so has
been less active with 3.11.  He deserves a lot of credit for earlier
work and I'm confident you will be hearing more from him soon.

On the subject of opening up and simplifying the process of submitting
modifications for Squeak:  I'm all for a certain level of anarchy here.
I hope to help out with this wherever I can, thanks for thinking about
it and I hope to see some results sooner than later.

Ken

On Tue, Feb 17, 2009 at 09:02:09PM -0800, Andreas Raab wrote:
> Igor Stasenko wrote:
> >So far i've collected 5 messages..
> >Hey, wake up! We need more! :)
>
> You're right. After some careful consideration I've decided to throw my
> hat in the ring as well. Count me in.
>
> I'm doing this with a clear agenda: I want to (re-)enable a process by
> which contributions flow into Squeak, both small and large.

Bravo. Thank you for deciding to run Andreas.

Dave

Hi Andreas,

I am very happy you decided to run.  With all the advancements going on we
really need to focus on making it easier for people to contribute.  

This is a great step in the write direction.  :)

This is a very exciting year to be in the Squeak / Smalltalk communities.

Thanks you for running!

Ron Teitelbaum

Andreas Raab wrote:
> Igor Stasenko wrote:
>> So far i've collected 5 messages..
>> Hey, wake up! We need more! :)
>
> You're right. After some careful consideration I've decided to throw
> my hat in the ring as well. Count me in.
>
> I'm doing this with a clear agenda: I want to (re-)enable a process by
> which contributions flow into Squeak, both small and large.
This was exactly my vision too. As the developer of Rio, I could see no
possible existing process by which Rio could be adopted into the
mainstream, (Rio just being a representative example of a relatively
significant but not huge change), I could list numerous other examples
(Namespaces etc).

I expect that the process of introducing such a module needs to be
planned. tried, experimented with some feedback gained. Pilot versions
of squeak with the integration of the new feature might co-exist with
the standard versions, until such a time as an effective transition can
be planned.

This is possible with the current process, but only just. Firstly, the
new module has to be completely ready, since the release team is only
really supposed to be integrating. Secondly with the release team leader
in the benevolent dictatorship role he, and only he has the ability to
integrate the module in short incremental steps. Pulling out such a
module at the 90% mark would probably be tricky. Such transitions are
all or nothing, there is no waiting room, where a new idea can gestate
and mature into place.

We lost the ability to say "we need this" and to plan for its
development and evolution, instead we only have the option of using what
is essentially complete, and then at the risk of upsetting/alienating
those whose code breaks as a result. Agreed.

Our new framework has places to put new ideas, so if you wish to add the
Nile api to an earlier version of squeak, then LevelPlayingField or
Sake/Packages have a place you can do so. If you wish to remove a
package from the kernel, then a Sake/Packages unload script can be
developed. If you want to intergrate something new, then aim would be to
define a task, "integrate Nile". This task can tested out now and be
scheduled in as part of a planned future release, say 3.12.

The release team then applies the tasks to generate the build, but there
is nothing stopping another variant image being generated from a similar
set of tasks.

As I see this, this is a licence to fork. However if we empower people
to fork and test their ideas within the same framework, where such
innovations are visible, this promotes an overall meta-compatibility
between the forks, through the exchange of ideas, and visibility.

For example, if I can see all the places where people are adding
extensions to Collections, then I have the information I need to design
a new streamlined Collections package that will suit everyone, with
additional loadable non-core collections modules.

The hope is that the community will have the best of both worlds. The
ability to try out new things, and the ability to share, exchange and
update the best of the common stuff.

My sadness of the approach of the pharo project is the irony that at the
exact same time we have been talking about a process that would
facilitate new ideas, and different forks of squeak both existing and
new. They choose to fork outside of that new proposed process, and carry
on using the old, one perfect path philosophy.

Its like having discovered that the square pegs (banches of new
innovation) don't fit through the round hole (the incremental, 2 person
release team),  lets go off and make a round peg (our one new
streamlined branch of new innovation) which is compatibile with our hole
(incremental, 2 person release team). At the very same time that those
with the square peg (branches of new innovation) decide to adopt a
square hole (a philosophy and framework for facilitating and embracing
branches of new innovation).
> All of the above exist. These aren't projects that someone will only
> start if given assurances about their outcome.
Right, and this was exactly my issue with Rio, from the outset the
integration looked like it would never happen.
>
> Similarly, Keith and Ken are building some fantastic tools for getting
> stuff out of Mantis. Why not build a network of trust for people who
> can add candidates to the next Squeak version which is rooted at the
> board? In other words, if you have been blessed by any of the board
> members, you could add your fix straight to the next alpha build.
yep, agreed.
>
> The above are all examples of things we can try. I'm not saying any of
> those is the right solution but I am asking for a mandate in trying to
> establish a process that will allow us to continually improve Squeak.
I was a little bit forward, when I figured I could take hold of that
mandate myself. In the void of vision, that was present after 3.10, the
board were even considering not having a 3.11 at all.

I figured that it was better to take the opportunity to try something
new, than to keep on with the same exsting process that wasnt really
happening. I know Edgar pushed for more of the same in his 3.11 efforts,
but the will didnt seem there to support the same approach ad infinitum.

I gtg, but its very very encouraging to hear you sharing these ideas. I
know we dont have all the answers and we have a bit of exploration to
go... but I do think we might just be able to make this fly

Keith




 when I heard it muted that some considered that 3.10 was the end of the
line for the current iteration of the kernel.