Introducing: the Lyceum Forum!

The Lyceum Forum is now live!

http://forum.lyceum.ibiblio.org/

Thanks to everyone who contributed to the forum software discussion. I’m quite happy with Vanilla so far.

The user database for the forum and the wiki are now the same. Accounts created on the forum will work on the wiki.

Special note for users who already have a wiki account: Previously created wiki accounts will NOT work on the forum until they are registered on the forum. You also will not be able to log into the wiki until you create a forum account. What this means: if you have an existing wiki account, you should register on the forum with the same username as soon as possible.

Yahya Hamidaddin’s theme porting advice

Lyceum user Yahya Hamidaddin has ported a couple database-using WordPress themes to Lyceum (themes that don’t use the database need little or no modification). He has been kind to share his experiences with us on the Lyceum wiki, here and here.

Thanks Yahya!

WordPress 2.1
Akismet in Lyceum 0.34

I forgot to mention some big news in the Lyceum 0.34 announcement: Lyceum 0.34 now ships with a Lyceumified version of the world’s best web spam filter: Akismet.

For now, Akismet must be activated on a per-blog basis, and each blog must have its own Akismet key. A page on the Lyceum wiki has more info on Akismet and Lyceum, including how to acquire an Akismet key. Please update the page with your own observations and tips!

Lyceum 0.34

Version 0.34 of Lyceum has been completed. This release brings some support for importing data from other blog systems, and the usual smattering of refinements and bug fixes (some of them rather significant).

Go check it out in the downloads section. Bring problems and suggestions to the email list and irc channel.

Which forum software should we use?

We are going to install forums software for Lyceum. The two that I am considering are PunBB and phpBB, mostly because they are the only ones with which I am at all familiar.

There was some discussion on the lyceum-users list a few months back about forum software, beginning here. Folks mentioned a couple other projects: FUDforum, and Vanilla.

Eventually we would like to synchronize the user databases between the forums, the wiki (MediaWiki), and the add-ons repository (Trac), so if any of the forum software packages are particularly good at at that, let us know.

(Another question is, which url should we use?)

WordPress 2.1 Database schema and variable changes

There’s a post on the WordPress development blog outlining some changes in the upcoming WordPress 2.1. These are all welcome and sensible changes that will be merged into Lyceum when the code is final.

Trac is back, better than ever

The trac service is back, running nice and snappy on its new postgresql backend.

Big thanks to John and Jon (and of course me, John) for making this happen.

Lyceum svn and trac services going offline tonight

We are upgrading and tricking out our trac and svn systems tonight, so they will be going offline starting around 9:30 pm US Eastern time, and coming online many hours later in the dead of the night.

What CRUD capabilities do you want in Lyceum?

I was having some frustration just now while trying to configure our Trac system. Deletion of tickets and ticket comments is not a standard feature in Trac, and must be added using the WebAdmin and TicketDelete plugins. These have worked perfectly for us in the past, but broke when we upgraded to Trac 0.10. I’ve been trying to install their new versions, with no luck. I find it very frustrating that this functionality is not part of the standard Trac system. Of course, it being open-source, that means I should write/fix the problem myself.

But it made me realize something. I think the frustration I was having fits a common model in open-source projects: users get frustrated when what they consider to be basic CRUD features are not provided with software. And it’s true, these features do tend to get left out of otherwise feature-rich open-source projects. I think there are a few reasons for this phenomenon.

First, developers tend to prioritize features in terms of frequency of use. Even if implementing a given feature is easy, if it isn’t going to get used by the vast majority of users (according to the developer’s anecdotal subjective assessment), it gets a low priority.

Another reason, and I think this is the more predominant factor, is that developers have to draw the line between theory/Best-Practices, and practicality. For example, in the case of Trac, I’ve seen it mentioned on IRC and the email list that in theory, a ticket should never need to be deleted. It should just get marked as invalid, redundant, etc. However, this does not take spam into consideration. Here, a developer might have the tendency to think “well, this means that we need an excellent anti-spam solution. We will have it in the next version. No need for ticket deletion.”. Meanwhile, thousands of users, who are perfectly willing to go through the manual labor involved in clearing out spam, have limited tools to use.

And these are hard decisions to make, believe me. Looking at ANY single simple-feature example will make it seem like a no-brainer, but it’s perhaps easy to forget that there are dozens, if not hundreds, of such simple features that can be implemented for a given project. So we must conclude: the developer’s masterful instincts should always be trusted :).

But today I decided that there is an exception to that conclusion: basic CRUD.

For example, in Lyceum, there is no way to completely delete a user or a blog. You can “deactivate” both of these things, and I always figured that for the time being this was enough for basic removal of spam sites and such.

But I can imagine users being very frustrated that they can’t delete users they made when testing their system, or users that were created with typos. Also, the process of reclaiming a blog slug is tedious. The system-admin needs to go to that blog’s admin interface, rename the slug with ‘_deactivated’ or some such namespace-safe string, and then go to the system-settings and deactivate that new slug.

The lack of such features might contribute significantly to making a user’s initial experience with Lyceum negative. Putting together a simple tool for permanently deleting a user or blog would be quite easy.

What these examples exemplify is that basic CRUD features are the building blocks of an unanticipatable array of administrative tasks, and so the best way to realize tomorrow’s features today is to provide a smattering (dare I say “complete”) offering of CRUD features. This is directly in line with traditional unix philosophy.

I give you JJB’s 1st Law of Feature Prioritization:

CRUD features should be prioritized over more abstract, heuristically driven features. Furthermore, developers are in the worst position to know which basic CRUD features are needed. These decisions should be driven by users, and the developers should humbly follow.

Pretty fancy huh? Anyway, the main point of this entire post is to solicit input from you on Lyceum. So I ask you, dear current or potential Lyceum user: what basic CRUD tools would you like to see added to Lyceum?

  • user deletion
  • blog deletion
  • what else?

Leave your suggestions in the comments below.