quassel-users November 2013

quassel-users@lists.quassel-irc.org

3 participants
3 discussions

Moving Quassel forward
by Bas Pape 04 Dec '13

04 Dec '13

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/

4 5

Server Outage
by Manuel Nickschas 26 Nov '13

26 Nov '13

Hi all, some people may have noticed that quassel-irc.org as well as the mailing list server have been down for the past day or so. The reason was a (planned) move of the server into another data center, followed by a problem with one of the RAID disks (that has since magically fixed itself...), follow by some early- morning admin stupidity that basically killed the mail and lists server. We now should be up and running again. Fortunately, I seem to have been able to restore all of the data, so at least as far as I can see nothing got lost - however if you've sent mails to the list which don't appear in the archives, please resend. Please let me know in IRC if something's still broken somewhere. There will be a few more, hopefully much shorter downtimes as I continue to upgrade, optimize and generally improve things in the next few weeks; but that should be way less painful. Cheers, ~ Sput -- Manuel "Sputnick" Nickschas ("Sput" on Freenode) | (o< Member of the Quassel IRC Project - http://quassel-irc.org | //\ Come visit us in #quassel! | V_/_

1 0

Welcome to the new mailing lists for Quassel IRC!
by Manuel Nickschas 08 Nov '13

08 Nov '13

Hi all, finally (after years of pushing and prodding for it), we have mailing lists for Quassel IRC. While most of user support and discussions happens in our IRC channels (mostly #quassel on Freenode), using mailing lists have distinct advantages - in particular, there is an archive, and people can chime in asynchronously. So now we offer the following lists at <http://lists.quassel-irc.org>: * quassel-announce This is a read-only list, where the development team will send important announcements to. We highly recommend distro packagers to subscribe to this one, as we'll announce releases and other important information here. * quassel-users This list should be used for general user discussion about and around Quassel IRC - questions, tips & tricks, that sort of things. * quassel-devel This list is for discussion about development of Quassel IRC itself. Everything that is related to development should go there, and we'll share our plans and ideas there as well. So, feel free to go ahead and subscribe! Please note that this is my first time setting up a list server, so if the lists show unexpected behavior or have configuration issues, feel free to poke me so I can fix it. ~ Sput, on behalf of the Quassel Project -- Manuel "Sputnick" Nickschas ("Sput" on Freenode) | (o< Member of the Quassel IRC Project - http://quassel-irc.org | //\ Come visit us in #quassel! | V_/_

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

quassel-users November 2013