IMPORTANT: Election candidates!

Hi all!

As you know we have an ongoing campaigning period for the Election 2010
that ends on the 3rd of march!

This means time is short and AFAIK (unless I missed someone, please tell
me) we have 6 candidates for 7 seats!

Unless we get more than 7 candidates there are three scenarios:

- Go through with the election process (to see how they rate against
each other) anyway. Kinda pointless.

- Skip the rest of the election and just take the 6 we have!

- Lower the number of seats in the board and go through with the election.

...ehm, or something else really clever. :)

Now, people - please step forward as candidates or please express your
feelings about my thoughts above.

regards, Göran

On 01.03.2010, at 11:52, Göran Krampe wrote:
I nominate Michael Haupt.

He is bringing new blood to Squeak - his students at the U of Potsdam worked on SqueakSVN, NXTalk, or PhidgetLab (won an ESUG Innovation award). More projects here
http://www.hpi.uni-potsdam.de/hirschfeld/projects/
Because of introducing new programmers to Squeak he also has an eye towards making it more accessible. For example, he co-wrote “An Introduction to Seaside”.
And I like his few but thoughtful messages on squeak-dev :)

- Bert -

On 01.03.2010, at 11:52, Göran Krampe wrote:
Also, I surely hope more of the current board members will offer to re-run. Come on guys! There has been an unfair share of bashing we got this term, but overall it was still a good year, don't you think?

- Bert -

Hi,

thanks, Bert.

People will probably want to know what I'm up to, and what I would try
to push and/or achieve as a board member. I'm mostly concerned about
these three topics:

Documentation.
Interoperability.
Process.

I will elaborate on each of those a bit now. Feel free to comment,
disagree or agree as you wish. I will try to answer as much as
possible.



Documentation. In my opinion, having more, better, up-to-date and
coherent documentation of all aspects of Squeak is crucial to avoid
people shying away from the sheer complexity of things, and to get
more people involved in the long run. A couple of ideas I'd like to
promote:

* a beginners' book introducing programming in Smalltalk (for pupils:
not Etoys, not the gory details, but Smalltalk programming gently
introduced)

* screencasts to show how the tools work

* proper documentation on virtually everything (where is comprehensive
documentation about tool X? how do I assemble a GUI in Morphic? ...)
in one place (or linked-to from one place)



Interoperability. There are some projects that were spawned from
Squeak; Pharo and Cuis are perhaps the most popular ones right now.
Things are floating back and forth between them, and that is good. I'd
like to foster this, as it is important to support each other. For
instance, having Seaside as an easily loadable package in Trunk is
just plain good.



Process. When the entire Trunk thing started, I was a little confused
about where it would lead release-wise. Things have been clarified
only very recently. I'd like to have very clear objectives for the
"next release" every time, and early decisions about who is
responsible for what. I know these things have existed in the past,
and I think having them is good because they provide clarity.



So far for now. If my counting is correct, there are now more
candidates than positions. Good. :-)

Best,

Michael

2010/3/1 Michael Haupt <[hidden email]>:
Hi Michael!

Do you have an actual timeline approximation in regard to the
implementation of these ideas? I'd like to know what are your
priorities in term of documentation since it's a one-year mandate; not
everything will see the light of the day during that period of time.

It would be also interesting to know which media you will focus on
(e.g. wiki, inside squeak, etc)? Have you tried HelpSystem?

Ian.
--
http://mecenia.blogspot.com/

Ian,

On Mon, Mar 1, 2010 at 4:26 PM, Ian Trudel <[hidden email]> wrote:
> Do you have an actual timeline approximation in regard to the
> implementation of these ideas? I'd like to know what are your
> priorities in term of documentation since it's a one-year mandate; not
> everything will see the light of the day during that period of time.

the mandate is not necessarily connected with getting a full set of
documentation out the door. Creating, establishing, and fostering the
infrastructure required to enabling the community to provide these
elements is what I have in mind foremost. Obviously, I would try to
contribute my share, but I think the board member's role (that is, as
long they have that hat on) is more on the infrastructural side of
things.

> It would be also interesting to know which media you will focus on
> (e.g. wiki, inside squeak, etc)? Have you tried HelpSystem?

I haven't (not *really*), but that is a good step in a sensible
direction. As for other media, anything is imaginable, but I believe a
Wiki (one that is kept up-to-date) would work very well, but also
don't forget the screencasts and book.

Best,

Michael

Regarding keeping docs up to date - I personally do NOT believe in
external documentation, we have tried that several times and failed.

Instead I believe something like the Magic Book could work:

http://wiki.squeak.org/squeak/3004

...of which the essential idea is to use unit tests and connect them to
"chapters" of documentation, when unit tests are updated, that typically
signals that APIs have changed - and thus chapters are marked as
"possibly stale".

regards, Göran

2010/3/1 Michael Haupt <[hidden email]>:
Yes, obviously. That's a bit politician talk though. :)

My concern in your list is that the priority seem to be focused on
entry level book(s). There are already existing work such as Squeak by
Example and Laser Game tutorial. They're good enough to get started.
On the other hand, the documentation inside Squeak may be more urgent.
There are comments and code self document but it's always up to the
point. There is a huge lack in term of the big picture and how to tie
what you learn from reading code. Sometimes it turns out a lot of code
reading to do very little.

>> It would be also interesting to know which media you will focus on
>> (e.g. wiki, inside squeak, etc)? Have you tried HelpSystem?
>
> I haven't (not *really*), but that is a good step in a sensible
> direction. As for other media, anything is imaginable, but I believe a
> Wiki (one that is kept up-to-date) would work very well, but also
> don't forget the screencasts and book.

Wiki doesn't seem to cut it so far and it's overly outdated; dragging
this to a decent point may be a considerable challenge (more than
starting over). My idea would be to focus on documentation inside
Squeak and develop a documentation system that can render help inside
and perhaps web friendly.

> Best,
>
> Michael

Thanks Michael!

Ian.
--
http://mecenia.blogspot.com/

Hi Göran,

2010/3/1 Göran Krampe <[hidden email]>:
> Regarding keeping docs up to date - I personally do NOT believe in external
> documentation, we have tried that several times and failed.

are you saying in-image documentation works? ;-)

> Instead I believe something like the Magic Book could work:
> http://wiki.squeak.org/squeak/3004

Very good. I like the idea of exploiting tests for that purpose very
very much. But it requires there to *be* tests, and the documentation
needs to be *maintained*. This is where the problem is; I don't think
it's about external ./. internal.

How often do you write code and not document it?
Worse: how often do you change code (interface) and not document it?
(This is not for you in person, Göran - anyone should ask themselves
this question. My own answer is depressing as well as probably most
others'.)

Best,

Michael

Hi Ian,

On Mon, Mar 1, 2010 at 5:29 PM, Ian Trudel <[hidden email]> wrote:
>> the mandate is not necessarily connected with getting a full set of
>> documentation out the door. Creating, establishing, and fostering the
>> infrastructure required to enabling the community to provide these
>> elements is what I have in mind foremost. Obviously, I would try to
>> contribute my share, but I think the board member's role (that is, as
>> long they have that hat on) is more on the infrastructural side of
>> things.
>
> Yes, obviously. That's a bit politician talk though. :)

guess what. You read the note about having the board hat on, right?

> My concern in your list is that the priority seem to be focused on
> entry level book(s). There are already existing work such as Squeak by
> Example and Laser Game tutorial. They're good enough to get started.

You got me wrong there; I'm not about *this* level of entry. There is
a level between that of the Etoys target audience and (S/P)BE or laser
game adopters, and my idea of an intro book for children targets
precisely this level.

> On the other hand, the documentation inside Squeak may be more urgent.
> There are comments and code self document but it's always up to the
> point. There is a huge lack in term of the big picture and how to tie
> what you learn from reading code. Sometimes it turns out a lot of code
> reading to do very little.

You make my point.

> Wiki doesn't seem to cut it so far and it's overly outdated; dragging
> this to a decent point may be a considerable challenge (more than
> starting over). My idea would be to focus on documentation inside
> Squeak and develop a documentation system that can render help inside
> and perhaps web friendly.

Yes please.

Note that I'm not trying to promote concrete "do this" items as much
as "something needs to be done about this, what could that be and how
could the requirements be met".

Best,

Michael

Hi Michael,

>> Yes, obviously. That's a bit politician talk though. :)
>
> guess what. You read the note about having the board hat on, right?

You're not on the board just yet and I welcome a sense of direction from you. :)

>> My concern in your list is that the priority seem to be focused on
>> entry level book(s). There are already existing work such as Squeak by
>> Example and Laser Game tutorial. They're good enough to get started.
>
> You got me wrong there; I'm not about *this* level of entry. There is
> a level between that of the Etoys target audience and (S/P)BE or laser
> game adopters, and my idea of an intro book for children targets
> precisely this level.

Thanks for the clarification. We've talked about children using Squeak
during last year but it's not a good demographic. They're not going to
get involved in developing Squeak itself before another, say, 15
years. My opinion is that the target audience should be Squeak
developers and the rest will naturally follow in due time.


> Note that I'm not trying to promote concrete "do this" items as much
> as "something needs to be done about this, what could that be and how
> could the requirements be met".

I understand your point. I am very much for a documentation team. It
wouldn't hurt to have a more specific plan/direction from you, even if
it does not include concrete solutions.

Ian.
--
http://mecenia.blogspot.com/

Hi Ian,

On Mon, Mar 1, 2010 at 6:04 PM, Ian Trudel <[hidden email]> wrote:
> You're not on the board just yet and I welcome a sense of direction from you. :)

there is and will always be - I was trying to give it to you; it's at
another level. Please accept that I do not want to fix any plans just
yet. I am collecting ideas. I really want to understand what is
important and help moving that forward. Improving documentation both
inside and outside the image (inside: rather API documentation,
outside: rather tutorials or even more complex things) is what I
intend to advance.

Sorry if it's not any more clear to you, but that's what I intend to
do at the "political" level - and board membership is such a thing.
:-)

Ah well, OK, misunderstanding again, this time, I was not clear
enough. This was not to say I'm happy with the amount of documentation
available for those in the focus of Etoys or full-fledged advanced
Squeak. But there is a hole in the middle between those, and this is
what the intro book item in my list is about.

The documentation thing is certainly more than just one strain of work ...

> I understand your point. I am very much for a documentation team. It
> wouldn't hurt to have a more specific plan/direction from you, even if
> it does not include concrete solutions.

Anything I write will be too meta for you. :-)

Anyway, here's an attempt.

First, form a documentation team representing different stakeholders,
identify issues that need to be addressed (poll?), think about how to
address those (technically, socially, whateverly).

Next, come up with solutions that can advance in close connection to
the advancement of the trunk (documentation not necessarily hard-wired
with single packages, but connectable, versionable, (un)installable,
and appropriately updateable - this is rather about in-image "API"
documentation). The overall idea is to keep the documentation in sync
with the system. Also, sketch tutorials on identified issues, ask
experts (developers?) to contribute, have them completed and posted
and, afterwards, kept up-to-date. These ideas will require ongoing
efforts on behalf of everyone involved.

Meantime, in a different branch, think about how to shape and create
an entry-level book for the target audience mentioned above. Find
people that want to contribute, agree on contents and structure, write
write write, throw at people, see how it works, refactor, etc.

This *will* take more than a year. But these things just have to be
kicked off some time. Squeak is just too good to be under-documented,
it does not deserve this.

Best,

Michael

2010/3/1 Michael Haupt <[hidden email]>:
> Hi Ian,

Hello Michael,

Sure, I understand. I was outlining the fact that one runs for the
board and gets elected: it means to have a plan and be appealing to
the voters.

> Ah well, OK, misunderstanding again, this time, I was not clear
> enough. This was not to say I'm happy with the amount of documentation
> available for those in the focus of Etoys or full-fledged advanced
> Squeak. But there is a hole in the middle between those, and this is
> what the intro book item in my list is about.
>
> The documentation thing is certainly more than just one strain of work ...

My point is also that Squeak developers need a good motivation to work
on the ideas proposed. Anything addressed to children won't cut it
because we have no immediate use for it. This is perhaps where the
trunk comes successful because it is self serving and it generates
motivation and energy.

> Anything I write will be too meta for you. :-)
>
> Anyway, here's an attempt.

You're doing a fine job, Michael.

> First, form a documentation team representing different stakeholders,
> identify issues that need to be addressed (poll?), think about how to
> address those (technically, socially, whateverly).

I agree and I like your idea to query the community with polls.

> Next, come up with solutions that can advance in close connection to
> the advancement of the trunk (documentation not necessarily hard-wired
> with single packages, but connectable, versionable, (un)installable,
> and appropriately updateable - this is rather about in-image "API"
> documentation). The overall idea is to keep the documentation in sync
> with the system. Also, sketch tutorials on identified issues, ask
> experts (developers?) to contribute, have them completed and posted
> and, afterwards, kept up-to-date. These ideas will require ongoing
> efforts on behalf of everyone involved.

See, a plan is taking shape. It's important to write these things down
even when it's obvious, then we can bounce ideas to each other in a
productive manner.

Thanks for the clarifications!

Ian.
--
http://mecenia.blogspot.com/

Hi Ian,

first off, thanks for your many questions. I really appreciate that.
Having a hard time helps. :-)

On Mon, Mar 1, 2010 at 9:23 PM, Ian Trudel <[hidden email]> wrote:
> My point is also that Squeak developers need a good motivation to work
> on the ideas proposed. Anything addressed to children won't cut it
> because we have no immediate use for it. This is perhaps where the
> trunk comes successful because it is self serving and it generates
> motivation and energy.

You are right - but again, the documentation effort would not only be
about Squeak for developers, but also for Squeak for beginners. Why
should their parents get them a book on, say, Java, or, God forbid, C
when there was something for Squeak available?

>> First, form a documentation team representing different stakeholders,
>> identify issues that need to be addressed (poll?), think about how to
>> address those (technically, socially, whateverly).
>
> I agree and I like your idea to query the community with polls.

Well, what else?

> See, a plan is taking shape. It's important to write these things down
> even when it's obvious, then we can bounce ideas to each other in a
> productive manner.

In fact, the plan was there before. Formulating it for others really
helps, though. Again, thanks for asking.

> Thanks for the clarifications!

Sure.

BTW I just glimpsed at HelpSystem. Yup, that's it. Almost. Have you
looked at the API documentation? "This method has no comment" all over
the place. But hey, there's an *infrastructure* that will, if I
understand it correctly, help with *many* of the points I mentioned
earlier. Wishes emerge: usable documentation inside and outside the
image; navigability from code to documentation; ... wonderful work.
:-)

Best,

Michael

On Mon, 01 Mar 2010 11:52:51 +0100 Goran Krampe <[hidden email]> wrote:

> Now, people - please step forward as candidates or please express your
> feelings about my thoughts above.
>
I'll step foward even though I still feel like a newb compared to many of you. I have a demanding full time IT job as well as other interests in music, cycling, and old cars. After all that I run the Open Slate Project. My interest in Squeak is to make it the software platform for Open Slate. I admit I still have much to learn, and am willing to help in whatever way I can.
--
Gary Dunn, Honolulu
[hidden email]
http://openslate.net/
http://e9erust.blogspot.com/
Sent from a Newton 2100 via Mail V

I like your attitude and energy, Micheal.
I think you'll make a good board member. =)

Ian.

Ian,

Am 02.03.2010 um 04:55 schrieb Ian Trudel <[hidden email]>:
> I like your attitude and energy, Micheal.
> I think you'll make a good board member. =)

thank you.

Best,

Michael

>

> Also, I surely hope more of the current board members will offer to
> re-run. Come on guys!

     Okay, I'm in. :)


-C

--
Craig Latta
www.netjam.org

http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-September/139796.html

On 02.03.2010, at 07:05, Craig Latta wrote:

Yay, thanks :)

- Bert -