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.
The Squeak Oversight Board Blog 
June 14, 2009 at 5:47 am |
One could be heavy handed and filter based on date, and say for example , this page was last edited august 10 2002, and add a reference to the image released closest to that date.
June 14, 2009 at 7:30 pm |
This is a great first approximation, though I have seen several pages with really old content that had some tiny edit a few years later than most of the text.
Thanks for the suggestion!
June 14, 2009 at 7:48 am |
More advanced Swiki search facilities would be a good first step.
June 18, 2009 at 4:08 pm |
Could you be more specific? What search capabilities are you missing for http://wiki.squeak.org/squeak/search ?
June 21, 2009 at 7:56 am |
Date ranges, last time accessed, creator, editor/s, Squeak version that a page applies to (if/where possible. Maybe match last-edit to Squeak release dates as a first guess?)… anything in fact that help narrows the scope for any clean-up effort. Also IMHO the swiki, and wiki’s in general, are too passive. Submitters and editors should take some responsibility for their content and be reminded now again via email to review their content and notified when edits occur. Content should also be peer reviewed. There is no quick fix but a good start would be to mark all pages as “not checked”. I am against migrating to another wiki engine as it does nothing for the content and implies Squeak/Smalltalk is weak or incapable in some way.
June 17, 2009 at 9:04 pm |
I think that the constraint: “a new wiki, possibly based on some more modern Squeak technology” should not be established. The best tool for the job should be used no matter if it is not a squeak/smalltalk technology.
The problem with the squeak/smalltalk technology it is that it has very few developers adding new functionality/features/security patches to the code base and indeed, the new wiki site should be almost hassle free.
A wiki as wikipedia (http://www.mediawiki.org/wiki/MediaWiki) or like the one of Ubuntu Linux (http://moinmo.in/) should be fine.
With respect to the information of the current one, we can migrated one by one, with better quality, but motivated by the better look & feel of the wiki and the better features of the wiki software.
Personally I will migrate some pages from the old one to the new one given that the interface will make it attractive enough.
June 18, 2009 at 3:04 pm |
I strongly disagree: I try to “eat our own dogfood” whenever possible. So I use Celeste for email, eIRC to chat on #squeak and so on. We already have Mantis as a critical non Squeak based resource used by the community and previously we had SqueakPeople. I am not very happy with these, but that is just one opinion and we should discuss this more.
June 18, 2009 at 6:36 pm |
But I think that the “not invented here” syndrome has given more problems than it has resolved. Take the cryptography/openssl discussion in the squeak list of the previous weeks. And that is precisely the problem solved by the plugins in squeak. Not everything can be done in squeak, and if done, it can not have the sustained resources/effort/motivation to add new features and be on par with the “trendy” ones. But I’m not saying that a priori, the squeak based ones should be banned, but that the better tool should be used, no matter what technology it actually uses. As for mantis, I agree, it is ugly as ass, but, a wiki is not something that should be redone everytime in every language just for eat our own food.
I think that squeak and smalltalk in general is years ahead of others languages, but that doesn’t means that the “tools/applications” written in it, are years ahead of others. And in the case of the wiki, I strongly believe that the squeak ones have an abismal disadvantage respect to others.
Besides, the squeak board chose to use wordpress (not self hosting, not smalltalk, not even a non-default theme) to host the board blog and not something like pier and that doesn’t mean that pier is bad or that wordpress is better. It was just because the important thing was to REACH the community. The same thing applies to the wiki. Not many of us mind the tool you use, but the information stored there, for the community to USE and IMPROVE. With the current one, something as subjective as the look and feel of the wiki can have a big effect on the disposition of one to collaborate.
But as final words, that the best tool be the winner. Ultimately, the community is the important thing.
Cheers.
June 18, 2009 at 4:08 pm |
I agree with Jecel. While using other technology should never be entirely ruled out there must be significant reason to not use our own products.
June 18, 2009 at 5:42 pm |
Hmmm, “dogfooding” (as I have also heard it termed) can be helpful in improving the quality of the “dogfood”, but in the interim it can bring a lot of pain and inconvenience to those subjected to intermediate results. I have painful memories of being forced to use Lotus Notes when I used to work for IBM. AFAIK Notes has not improved radically to the point where it is a joy to use, so the approach doesn’t always achieve that aim. As the Wiki is a resource to be used by those new to the Squeak world, perhaps more so than for those who have already “drunk the cool aid”, should we risk putting off the newcomers because the dogfood has not reached the right level of maturity yet? Personally I don’t think so, but maybe that’s just me.
June 18, 2009 at 4:38 pm |
[…] The Squeak Oversight Board Blog Communicating with the Squeak and greater Dynamic Languages Community « garbage collecting the Wiki […]
June 19, 2009 at 12:31 am |
Miguel,
WordPress didn’t allow me to reply directly to your comment. Probably nested too deep or something like that. If only this blog were written in Squeak….
Just kidding! I agree (and so does Craig on IRC) with your argument that we are so few that nobody would ever get around to doing the desired changes anyway.
About the best tools – I have had some experience with several Mediawiki sites and two Pier based ones and my impression so far is that each has its share of problems. Being able to edit individual sections and the auto index are the main things I miss in Pier.
June 19, 2009 at 1:14 pm |
I’ve had pretty good experiences with Atlassian Confluence, which, although commercial, offers a free license to open-source projects that I think Squeak would qualify for – http://www.atlassian.com/software/confluence/licensing.jsp#nonprofit
June 19, 2009 at 1:38 pm |
FWIW, I think a new communication engine based on google wave protocol would be just perfect but this would involve building our own clients and protocol implementation first, so lots of work.
I really find wave is a very flexible approach to communicate, collaborate, search, make the content evolve etc…
What people think about porting the protocol (wave, wavelets, …) to smalltalk (maybe an esug talk project ?)
June 22, 2009 at 4:57 pm |
Thanks doc (and everyone else who has replied):
All good suggestions and worth consideration, and I agree that a more active wiki would be great. There are some technological addons such as you suggest that could help, but at the moment there is no ‘editor’ or even really ‘authors’ to which these things could be pointed.
In fact that is the core goal with this blog post: Technological suggestions are great and are needed but in the end don’t get us anywhere without people with sufficient interest to carry through with the ideas.
Also I want to be clear that we are not precluding continuing to use the Swiki software, perhaps with some additions and upgrades. In Jecel’s comment “a new wiki” might just as readily mean a new Swiki instance. It might mean exactly the same Swiki instance we currently have with some changes and a new life. It’s more the philosophical idea of a “new wiki” we are concerned about; a reborn wiki. If it appears that entirely different software is more likely to get us to the desired goal, so be it. But there are plenty of ways to also leverage the flexibility of Swiki.
June 26, 2009 at 12:49 am |
My experience with the current wiki over the years can be summarized in one word: useless. It’s disorganized, outdated, unusable code, etc. I am not even bothering with it anymore. Ever.
One a great asset in Squeak’s philosophy is being self-sufficient. The question is: why don’t we get to manage our documentation within Squeak? As a community documentation tool, both online and offline, we have more chances to produce quality documentation if it’s within Squeak.
Then it would be easier to attach versions, packages, classes, methods, etc. to documentation when we’re writing from the system. Especially that these can be tagged automatically.
Besides, the current swiki implement might not be enough for our growing needs. We should have an editing process where editor can review the documentation, which can be provided with every upcoming version of Squeak. Etc.
Squeak board could really help to create a sense of direction with some sort of official documentation, possible if we have a proper documentation system available within squeak.
June 27, 2009 at 10:45 am |
I agree that the quality of the current wiki’s content is low. However, I think moving to a new wiki is a terrible idea. Here is why:
Currently the biggest constraint seems to be lack of resources. There are simply not enough hours put into improving the wiki. Moving content to a new wiki will most likely take more time than improving the old one.
Therefore, we would probably end up with two worse wikis than the one we started with. It will further increase fragmentation which is already very high in Squeak with its many forks. And that feeds back into lack of ressources – a classical vicious circle.
Speaking of fragmentation – why aren’t we discussing that on the Squeak-dev mailing list?
What could we do to improve the wiki’s quality? Every month or so someone – perhaps a board member or better yet a documentation team leader – could send an e-mail to Squeak-dev, reminding people that
– the quality of the wiki is very important,
– that everyone – especially newbies – can help improving it,
– ask people to leave a comment on pages who are outdated and communicate it to Squeak-dev,
– thank people who did improve it.
The comment could have a standardized tag – e.g. #OUTDATED – so that all outdated pages can be found by a search.