A web site development proposal for ktorrent.org

In the previous pages, I was discussing the benefits of the Blog + Wiki + Issue tracker community web site concept. Though this concept is not limited to software development web sites (far from that), they are the prime target to implement it. http://ktorrent.org/ is one such site which would greatly benefit from a reorganization. In this article, I'll first describe the current web site organization, its strengths and weaknesses. Then I'll go over a proposed upgrade path to a fully integrated Blog + Wiki + Issue Tracker software development community web site.

4 software for one site

Currently the web site and the whole ktorrent project is articulated around 4 different software each performing a specific task.

First, we have a very basic Drupal web site which is used for the front page and to deliver news about the latest releases:
(click for full size).

The enhanced ktorrent web site will be built around this kernel Drupal web site.

Then we have a forum using the popular phpBB software:

The forum is used as an informal bug and feature tracker. As you probably have read in the previous pages, I have grown to hate forums (and phpBB) with a passion. The updated web site will use a combination of features (all powered by Drupal) that will be much more adapted to the uses that is currently made of the forum and that will serve the community much better.

Next, we have a wiki using the WikiMedia, the same software that powers Wikipedia:

I have previously discussed what I see as the single major flaw of wikimedia, namely the discussion pages. While the purely "wiki" aspect of wikimedia is great, I abhor its discussion pages and its community tools. I would much prefer a much simpler wiki, maybe with fewer features, but better integrated with the rest of the web site, and where the discussion can be better articulated and followed until the a logical and satisfactory conclusion of the point being discussed has been reached.

Lastly, offsite, we have the official bug tracker, hosted at http://bugs.kde.org/ :

Login problems

To be a full participant in the ktorrent project, one would need up to 4 different logins (password + username), one for each of the aforementioned software.

What happens most of the time is that when users have a request or need support, they will create an account in the forum and ask their question, expecting to get an answer but without considering the possibility of contributing anything back. The huge majority will have the good excuse of not being C++ programmers. Yet, most will not consider creating another account to help editing the wiki, even less a third account to file bug reports and feature requests where they logically belong: in the official KDE bug tracker.

In order to encourage the community of users to participate more in terms of documentation and bug triage, it is important to remove the hurdle of having to create different accounts. This will be the most important benefit of having an integrated web site.

The Forum

Forums encourage discussion... but not active contributions. A forum is great for a webmaster of a small web site and a forum with low to moderate activity. The webmaster can at any time follow all the ongoing discussions and remember what has been said and where. But this is a double-edge sword for the webmaster. First, he could have exactly the same benefits with a proper wiki and feature tracker. Secondly, in a traditional forums, newcomers do not have a proper perspective of everything that has been discussed. They won't bother reading the whole forum, and the search features are most of the time inadequate. All this conspire to encourage the users to come and use the forum as a free support system where they can come, ask, take and leaving without having contributed anything back.

There is no convenient classification of forum threads beside a vary basic sorting by topics ('development', 'support', etc.) Thus it is not possible to get a proper view of which threads are obsolete, which are still pending and still relevant, etc.

All of this puts the whole burden to the single webmaster, the only one to have, in his mind, a proper overview of the situation.

In this case, the webmaster is the single developer for the software. It would be better for the whole community if he could save his time, concentrate on what he does best while providing the tools to the community to have the same overview on what needs to be done, in terms of bug sorting, documentation, etc.

A traditional forum is not helping in this respect. Instead, since the forum is used an an informal bug tracker, the best would be to use a real bug tracker.

The role of the community

Currently, ktorrent is mostly a one-person project, with limited support from the community. The maintainer has wisely concentrated his attention on actual code development, to the expense of the web site development and of the documentation. After all, the community of users care more about a fully-featured, stable software than a pretty web site. Given the maintainer's limited time, it was the right choice to spend it where it has been the most appreciated.

However, a well-organized, fully integrated web site that provides to a larger community the tools to organize itself is opening new possibilities for the whole ktorrent project. It is important to keep in mind that there would be a fair number of people interested in actually contributing some of their time. Certainly not everybody has the ability to code in C++ and provide actual patches. However, each individual has their own abilities and should be able to contribute accordingly.

Thus it is proposed that the current maintainer continues to focus of what he does best: develop the actual software. With this proposal, I kind of volunteer to take on the maintenance of the web site. With the new web site set up, we'll be able to customize user permissions, allowing interested contributors to complement the documentation, do bug triage, etc.

With the single login setup, users who register to ask a question, report a bug or request a feature would automatically have access to edit the wiki. With one hurdle less, it can be expected that some of those users will actually contribute something back to the whole project, especially in terms of documentation and bug sorting.

Also, the web site settings can judiciously be adjusted so that users are, by default, automatically subscribed to the issues they participate in. Thus, each time a new comment is posted in those issues, they will receive a reminder: often, the only thing missing before the issue can be closed would be some documentation.

Spam

I noticed a lot of spam in the forum. Even though the current maintainer does his best to deal with it, I noticed some that was left in place.

This is typically the kind of maintenance task that the webmaster could delegate to the community. Regular users could use the appropriate 'project' in the bug tracker to report the spam and trusted moderators would be able to deal with it.

Upgrade path to a single, integrated web site

We have seen above the 4 software currently in use. Let's review each one of them to see how each one will be dealt with.

Drupal

Drupal is currently used to power the front page with the latest news. This will be used as the kernel around which the new web site will be built. New modules can be easily installed and enabled to cover all the functionalities covered by the other software.

Wikimedia

Wikimedia's wiki functionalities are an overkill for a small wiki like ktorrent's. A simple wiki can easily be set using core Drupal modules. Additional contribution modules can be used to complement the wiki's features, where required.

The current wiki is mostly empty: there's only 2 or 3 pages of actual content. It will be easy to move the content by hand into the new wiki. After that, the whole wikimedia installation can be removed from the web site.

phpBB forum

For the reasons explained above, the forum has been much more used than the wiki. There are over 3 300 topics, about 18 000 posts and 3000 members.

The first idea would be to import all of this into the new web site. However, I suggest that it would impractical and certainly not worth the effort.

There exists a contributed Drupal module designed to import a whole phpBB forum with its users into a Drupal site. I know this module well since I created it and I was its maintainer for a few years before passing on the torch.

However, there are two major problems with this module:

1- It will import the phpBB forum into a Drupal forum but our goal is to get rid of the forum altogether. We don't want a Drupal forum. If we wanted to import the phpBB forum into the Drupal bug tracker, we'd have to spend a fair amount of time to adapt the module and test it.

2- Even if adapted the module to import the forum into the bug tracker, it wouldn't be worth our time. We'd be mostly importing obsolete threads, resolved issues, unreasonable feature requests as well as support requests that have been dealt with. Also the huge majority of the registered users are not active: they came to ask a question, got (or not) what they wanted and are not likely to come back.

What I suggest we do instead is the following:

1- park the phpBB forum into a temporary archive. It currently occupies the http://ktorrent.org/forum/ namespace which we won't be using, so it can be "parked" in situ.

2- activate the Drupal bug tracker and lock the phpBB forum to new registrations and new threads.

3- ask people to register an account in the new Drupal site. Many of the accounts are dead. We may as well start from a clean slate. Interested users can easily register on the Drupal site, the last registration they'll ever need to make at ktorrent.org.

4- a special 'project' could be opened in the new bug tracker to go over all the posts of the old forum. For each thread in phpBB, the new web site contributors should be able to decide whether to have the thread deleted (by specially appointed moderators) if that thread does not contain any information that's still relevant today, or imported manually into the new bug tracker, if it deals with a current bug or a reasonable feature request, or manually added into the wiki if it includes information that could still be useful to current users. One we've made sure that all the useful information present in the old forum is also present in a more organized fashion in the new web site, the old forum threads can be deleted. It is to be noted that the software developer wouldn't need to take part in this process: the community is better off if he spends his time coding. The process of pruning the old forum and importing the information until it is completely empty can take as long a time as necessary; it will depend on how many members are involved in the process. Until then, the phpbb forum can remain parked where it is as long as new registrations are blocked and regular, existing users cannot post new comments/threads.

The new Issue tracker

The new issue tracker can easily be enabled in the Drupal site. The advantage is that we can have several 'projects' all connected to ktorrent. One project is the software itself. Another is all the issues concerning the web site (design, features, etc.) A third project would correspond to everything corresponding to documentation and the wiki.

We can add a few additional modules to enhance the Issue tracker, one of which will link the wiki to the Issue tracker. Thus, for each wiki page, we'll know which issues are still outstanding. The discussion will not be cluttered by resolved issues.

The KDE bugtracker

The KDE bugtracker would obviously remain. We can't get rid of it :)

It is to be expected that the new Drupal bugtracker will become the main, official bugtracker, and this is the one most of the community will use. However, existing kde.org users may find it more convenient for them to use the KDE bugtracker. That's ok. Its use would be marginal and issues there can be cross-linked to issues at ktorrent.org. It won't add much more work and it certainly won't be worse than the current situation.

Another advantage of the new issue traker over the KDE tracker, is that ktorrent issues are much more easily found by occasional visitors. In the KDE bug traker, there is no single page one can visit to see all outstanding ktorrent issues. One has to register and perform a search. In the new issue tracker, all ktorrent issues will be listed in a logical, easily identifiable place.

Blogs?

I started this proposal by presenting the Wiki + Bug traker + Blog concept. We have covered the wiki and the bug tracker. Their uses and raison d'etre are obvious.

But so far, we have not discussed the use of blogs at all.

My first thought was a site like ktorrent.org does not need any blog at all. All user activity boils down to a bug report, a feature request or a support request, all of which can properly be handled by the Drupal bug tracker. And everything that can be documented can be added to the wiki. It seemed that wiki + bug tracker cover all the current needs of the site (in addition to the existing node type used for the new release announcements made on the front page).

But then I started thinking what uses could be made of the blogs if each users were allowed to have their own?

In the Blog + Wiki + Issue tracker model, the role of the blogs is to provide a convivial space where users can freely express themselves, their thoughts, their projects, etc.

The issue tracker is the work space: each issue represents a task to be done. The wiki is, together with the software, what is being worked on and represents the result of the community's contributions. The blog is then the rest area, the place to relax and socialize.

I'm now thinking it could be a good idea to enable the blog to all the users. They could use their own blog to discuss torrents and torrent news in general.

It would cost nothing for us to provide those tools to the users. Then we can sit back and observe what uses are made of them. Obviously we can establish a common sense policy of the kind of content that would be acceptable in the blogs. Moderators can help to make sure that such policies are adhered to.

Ktorrent.org is a good domain name, a nice name space. The blog section has the potential of becoming a popular, generic torrent information web site.