Subject to updates, please offer suggestions–
3.11 Status
4.0/Relicensing Status
Squeak Swiki update or replacement
Teams
Anything more?
Subject to updates, please offer suggestions–
3.11 Status
4.0/Relicensing Status
Squeak Swiki update or replacement
Teams
Anything more?
Once again we were all present for today’s meeting: Jecel Mattos de Assumpção Jr, Ken Causey, Bert Freudenberg, Craig Latta, Andreas Raab, Randal Schwartz, and Igor Stasenko.
We spent the bulk of the meeting talking about 3.11 status. We didn’t come to any significant conclusions but resolved to increase communication with the release team and compile as much information as possible about the current status of this project and where it is going next.
We also discussed the wiki (Have you read Garbage Collecting the Wiki yet?), what can be done about the ‘forking impulse’, the status of the work on a new Smalltalk standard, and the 4.0 relicense release; no concrete results on these ongoing projects yet.
We meeting again on July 1, 2009. Let us know what you think we should be discussing.
The wiki is a fantastic resource for the community. Any search involving “squeak” will certainly have a link to a wiki page among the top results. And when answering questions on IRC, I nearly always end up pointing out some wiki page as the source for additional information.
Unfortunately, a significant portion of the information available there is obsolete. It is very easy for less experienced Squeakers to waste a lot of their time following advice they found on some page without realizing that it no longer applied to any Squeak newer than 2.5! One way to solve this is for a team to scan the wiki looking for stuff like this and then updating the information. In practice this is simply too much work and is unlikely to happen in a larger scale than what has been done so far. An alternative, inspired on garbage collection algorithms like those implemented in the Squeak VM, is to start a new wiki and move only current information there. This might seem like even more work, but it can be done incrementally: any person searching for information and not finding it in the new wiki can copy it from the old one.
If access to the old wiki remains as it is now, nobody would have any incentive to copy information to the new one. The most radical solution would be to simply eliminate normal access to the old wiki – you would have to explicitly log on to it or something like that. This would quickly make it vanish from the search engines. At the other extreme, it would be simple to add a warning to all old wiki pages saying that the content is obsolete. That could be done with the “message of the day” mechanism (lately it has been broken and only showing one quote from me anyway). This is too easy to ignore, however. A slightly more complicated solution would be to patch the swiki code to show a warning that would be far harder to ignore. It might be interesting to include a link to the new wiki for any page which has content that has been moved there. One way to encourage moving content to the new wiki would be to disable editing of the old one (except for adding links to the new).
The goal is to eventually have a new wiki, possibly based on some more modern Squeak technology, that document the system as it is now. The best way to achieve this would be for the board to issue a request for proposals so that people interested could form a team to create the new wiki and patch the old one. This team would not be responsible for the content, except moving a few key pages themselves to get the process started. The details that I have mentioned above are only examples – the candidates would be free to suggest any solution they want as part of their proposals.
Personally, I am very interested in Squeak’s history and would not like to see the old information vanish entirely from the web. But I do agree that as things are now the noise is getting in the way of the signal and we need to cause a better first impression to people interested in Squeak and Squeak based projects.
Everyone made it this time and so the meeting was attended by: Jecel Mattos de Assumpção Jr, Ken Causey, Bert Freudenberg, Craig Latta, Andreas Raab, Randal Schwartz, and Igor Stasenko.
We started out finalizing the mission statement which has finally been published allowing us to move on to other topics. Please read and comment.
We have received replies to the team survey we sent out some weeks back and we discussed this somewhat but haven’t had the time to properly digest the data or come to any conclusions yet. In time the teams page will receive a significant update hopefully clarifying how teams are formed and work.
We discussed the Release team and have asked them for an update on progress. The team leader, Matthew Fulmer, recently moved to a new state, started up at a new university, and started a new job; so I think we can all understand that he has been too busy to make much progress recently. Matthew is going to be setting aside time soon to work with the Software Freedom Conservancy to work out what further work is needed to produce an MIT/Apache licensed 4.0 release that is acceptable to the SFC as a requirement for our membership.
I think everyone can agree that the community Swiki has aged poorly and can be very confusing, particularly to newcomers to our community looking for clear information. We are discussing a plan to replace the Swiki with a new system. Some of the requirements for such a system would be a clear link between the current Swiki and the new system at least during the development of the new system and not losing the Google links to the existing Swiki pages. We need the community’s assistance with this and welcome suggestions. Do you have a plan for updating or replacing the Swiki with a better documentation system while not losing it’s existing strengths? Please let us know.
On a similar note one of our long range goals is to encourage the incorporation of ideas and code from our related communities such as Pharo, Etoys, and Croquet and of course many others. Also we want to examine the reasons that forks occur and consider what can be done to make it less necessary for developers to do so. We need your thoughts and ideas. Please give us your comments on this subject.
Our next meeting will take place on Wednesday, June 17th, 2009.
Well it took a while but we have finally published a ‘Mission Statement’ for ourselves and it can be found listed on the right. Please let us know what you think.