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.
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.
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?
Leave your suggestions in the comments below.