Moving Quassel forward

Bas Pape baspape at gmail.com
Sat Nov 23 14:32:50 CET 2013


Hi all,

Now mailing lists are finally here after having pestered Sput for
a while, I figure I actually have to make use of them now too. You may
or may not have been aware of my umpteenth short hiatus, but this mail
is not about that. Development on Quassel has been slowing down for a
while now, despite its considerable, but quiet, userbase (the user
count in the IRC channel reached 500 recently). Basically the userbase
outgrew the project, the tracker overflowed and the project is still a
hobby one (and a young one at that). Here are some thoughts and
suggestions that would hopefully improve the situation in various
areas; these are mostly taken from / based on Karl Fogel's "Producing
Open Source Software" [1].

The first thing a user would see is most likely the website. Currently
it's a somewhat messy Drupal blog with the odd news item, an empty
Features page, an empty FAQ, links to Redmine and some other stuff.
The simplest way to improve things here would be to do a rebranding of
sorts by putting together a clean, simple website. I would suggest the
following things:
 - Just have a simple mission statement on the homepage (the current
   synopsis from the homepage combined with the About page and a
   screenshot),
 - Have a seperate news page (if there is an urgent item, put a note on
   the homepage with a link to the full item),
 - Features and requirements, just summarize some
   important features and the necessary dependencies (including those
   which are optional),
 - Development status, currently it's still pre-1.0 and slowly being
   developed, this would also be a good place to show the current scope
   (more on that later),
 - No FAQ, if necessary, do it as part of the documentation; ditch the
   wiki (more on that later too), and a possibly necessary login is an
   implementation detail that should not be displayed this prominently.

Secondly a few words on the issue tracker. I personally think Redmine
works quite well, the issues with Redmine itself mostly stem from
updating it and upstream maintenance. Switching to something else
wouldn't be much of a problem, but I think keeping repo integration and
existing IDs should be a priority.
  As for using the tracker, this needs much improvement on the
dev side. Issues need a quick intake, so that the reporter is still
interested and knows what he was talking about; either approve it as
soon as it is reproduced, or ask for more info. Currently there are 422
open tickets just lingering and lacking consistency in priority,
category etcetera. This last bit could be improved by having some
prominently displayed guidelines for filing proper issues. Don't assume
the user knows what info a developer needs to act upon an issue.
  It should be possible for issues to be filed entirely anonymously
(e.g. a needinfo issue can just be rejected after 3 weeks lacking a
response). If a login is a technical necessity (as is the case with
Redmine), clearly show the anonymous account which can be used.
Preferably anonymous users would still be able to enter an email
address for notifications.

Next up, releases. Currently releases are loosely time-based, mostly
synced to *buntu releases. This is actually neat, as it means
somewhat frequent releases, assuming changes were actually available.
Syncing never should be strict, as hurrying is no good for quality, and
conversely, reaching the goal early simply means an early release.
  Usually just before each release, all current pull requests are
merged. In my view it would be better to merge pulls more frequently,
this would make progress less intermittent, makes doing the release
itself less work, and perhaps most importantly it leaves more time for
testing. One considerable change in how things are coordinated would be
scoping features. After each release, make a list of things that would
be nice to have for the next version (if feasible; larger changes might
need some planning ahead). Don't be too conservative with regards to
feasibility, things can be descoped again, but it would be nice to have
an idea of what is going to happen. A nice side effect could be that it
might give a sense of direction users can influence.

The fourth topic, code, is oddly enough the shortest one; I simply
don't have much to say that would change things. Ideally every line of
code that goes into the repository should be reviewed. No comment
means it's unlikely the review happened, as hardly any patches are
perfect the first time. I myself hardly ever got comments (only on the
larger rewrites that are lingering on gitorious), and only a couple got
a correcting commit directly afterwards. It is important to be
critical, and - especially for frequent contributors - have the patch
be resubmitted if something was wrong. Only if it takes too much time to
go back and forth (e.g. a discussion without a clear direction) should
the correction be done in their place.

The fifth (and last, finally) topic is the most dreaded one,
documentation. It's most dreaded because it takes a large amount of
effort, it'll never be finished, and it's not written by its audience.
  Ditch the wiki, as it simply doesn't work. Getting documentation
done takes a more centralized effort, which also makes it easier to
ascertain consistency with regards to style, quality and scope. I think
a good way to centralize documentation would be to maintain
documentation in Markdown or a similar format in a git submodule,
perhaps with some scripting to turn it into a website (or maybe Ikiwiki
could be used). Even though I am not a fan of it for code, Github's
online editor and committing would make it simple for users to
contribute changes to the docs with minimal effort; I think Ikiwiki
optionally also allows for online editing.
  Documentation for users should be entirely seperate from
documentation for developers and both should be clearly indicated. Both
should be available in the all-on-one-page format and optionally with
seperate pages. Both should clearly indicate which parts need
improvement (explicitly asking for contributions), and which parts are
incomplete or missing (for seperate pages it would be preferable to
have a non-link in the ToC for missing content, rather than an empty
page).
  Documenting planned features in user documentation, possibly
including UI mockups etcetera, would enable users to chime in early and
improve the feature before it even gets written. Of course the fact
that it is planned, but not done, should be very clearly indicated.
  Lastly user documentation should be included with the release, in
both plaintext for easy searching and generated for easy browsing.
Including screenshots could indicate what areas of the UI need
improvement (which can also be indicated with a request for
suggestions), besides of course clarifying what button one is talking
about.

To conclude this rather lengthy mail, I'd suggest you at least glance
at interesting sections of "Producing Open Source Software" as it
tends to make pretty good recommendations. Chapter 8, "Managing
Volunteers", would be a good read for the Big Boss, as it states some
not always obvious things contributors often expect. A slightly more
proactive management would definitely help the project.

This mail was intentionally sent to -users, as this concerns not only
developers and the userbase is the group where contributors come from.
Your move. 

-- Bas Pape (Tucos)
[1] http://producingoss.com/


More information about the quassel-users mailing list