Moving Quassel forward

Manuel Nickschas sputnick at
Tue Dec 3 21:57:58 CET 2013

On Monday 25 November 2013 20:30:46 Bas Pape wrote:
Hi all,

> First off, I think I may have been a bit too specific with regards to
> my recommendations; I don't care much for how things are implemented,
> especially as I won't touch most things anyway. What matters currently
> is getting an idea of which things need to be done and how to run the
> project on a higher level. Of course it'd be swell if you feel like
> picking up something immediately, but but then it'd be best to discuss
> that topic in detail seperately.

Understood. However, specific suggestions are always welcome - as they form a 
base for discussion at the very least.

> On 2013-11-24 16:45:43 +0100 Manuel Nickschas wrote:
> > On Saturday 23 November 2013 14:32:50 Bas Pape wrote:
> > > The first thing a user would see is most likely the website.
> > 
> > Documentation, the nemesis of every developer, because it takes out even
> > more time out of the development budget. But of course, I fully agree
> > that these are good, and sorely needed, ideas.
> Documentation and the website are rather distinct topics. The website
> would mostly be a one-off rework and be low maintenance (depending one
> the level of automation for roadmap and such, but again, details).

Indeed. There's the website framework, which doesn't change all that much as 
evidenced by the current website.

That also contains the user-facing documentation (the stuff we have in the 
wiki now); of course that needs a different treatment to keep it current (or 
written in the first place...).

> > Yes. You've done tremendous work in triaging things, but we need more
> > volunteers who are willing to help with that.
> I've hardly ever properly triaged bugs. The only thing I did was close
> duplicates and mark things as solved.

Which is already a hugely welcomed effort, as it makes it easier to keep track 
of the things that are actually still valid...

> > Personally, I'm a huge friend of feature-based releases rather than
> > time-based releases anyway, assuming that it won't make us slack again.
> Normally I would agree, but currently that last part is a problem,
> which is why I like loosely time-based releases. Assume a couple of
> bugfixes and one feature some people like are the only things
> available; with a feature-based release, these would linger until more
> things accumulated; with a time-based release, they'd at least be made
> available at some point.

That is true. Hence the "assuming" part; as long as development is as slow as 
it is, it's a good thing to set a time limit. Although I guess i wouldn't mind 
to release more often if there's actually something worthwhile to release.

> > Now, I've been very forgiving (or sloppy) when it comes to things like
> > formatting and commit messages. [..]
> > This is in stark contrast to how we handle this at work, where commits are
> > not being merged until they're perfect in every respect. Of course,
> > co-workers are not volunteers, they're paid to do a good job, so they can
> > get a different treatment.
> Disagree, being paid means they don't have the choice to not do it, as
> well as not always getting to pick what to work on and when to do so.
> Contributors shouldn't be treated much differently, lenience with
> regards to time is expected, but not with regards to quality.

Hmm, I guess I'll have to try that out... 

> > Maybe nitpicking, if done nicely, isn't that bad? It would educate the
> > contributor to not make the same mistakes next time, and pay more
> > attention to provide high-quality commits in the future. Updating a PR
> > is easy. And the overall quality of the codebase would go up.
> Exactly my point. If people bother to contribute patches, they most
> likely also care about quality. If they are regulars, they are expected
> to adhere to style and quality standards.

... because that is most probably true.

> > I think I will be much more rigorous in the future when it comes to
> > accepting these things; hoping that contributors don't feel put off by
> > that.
> Just make sure to ask, rather than tell. If one can decline without
> fuzz, you might just have to do it yourself once a blue moon, but I
> doubt contributors would actually be annoyed by this.

Yeah, it's certainly important to treat contributors as what they are, helpful 
and very much appreciated volunteers with no obligation to do anything. And 
you're right, judging from my own feelings, I'm very willing to get my own 
contributions to a project into shape if the maintainers talk to me nicely.

> The reason I recommended to ditch the wiki is because it's an
> exceptionally freeform medium and everything added goes into
> "production" immediately. This would mean that in order to ensure
> quality, the wiki would have to be monitored actively.
> On IRC it was suggested a centralized effort could be done using a wiki
> too, but this would mostly mean just laying down some guides to denote
> areas that need work and perhaps limit scope to some extent. I highly
> doubt that such an approach would get things done and maintain
> consistency. Next to that, it would complicate getting plaintext docs
> and formatted docs for offline use (i.e. in the package).

So, yes. If we keep the docs inside the repo, we can apply the usual review 
process to ensure that they're high quality. And it would probably much easier 
to find trusted and capable reviewers for that part of the repo than it is for 
the actual code. That leaves the question of which format would be suitable...

> I personally dislike in-code documentation, even though they are
> closely related. For API docs it makes some sense (more so if it's
> actually documenting a public API), but the mess it yields just puts me
> off (I know folding helps, but still..). Besides that minor point, API
> documentation is only a small part of docs contributors need; as they
> are editing the code, the API is in their editor already, a higher
> level overview and the way things work together is much more helpful.

It was just an idea to use something already existing and suitable for API 
docs also for the user-facing documentation, as Qt does it. They have 
separate, non-code related .qdoc files that are processed by the same tools to 
create the website output we all love.

Of course, if we find a format that is more suited than, say, Doxygen, we can 
use that as well. Need to do more research on that (or, maybe even better, 
find people who have experience in that kind of stuff already...)

> > Note that we should think if it's possible to create and maintain
> > translations of the docs, too! With docs being in the repo, we could
> > maybe leverage Transifex for that... however, not sure if it's feasible.
> I realized this too when someone mentioned it on IRC. I'm having a
> hard time to think of a way to do this in a way that would not make it
> an utter pain for translators to keep up with the source language;
> might be worth looking at how others do that.


> I don't expect much problems getting a handful of contributors for docs
> once a proper infrastructure and trajectory are available. It'd be nice
> if some would-be contributors would speak up before you settle on
> something.

Yes, although the current number of subscribers suggests we may have to ask 
more aggressively in IRC. I'm also thinking about a blog post once things are 
taking a bit of a clearer shape.

> > Speaking of management - I fail to be a decent project manager (also I
> > would like to invest more time into code and less time into managing).
> > This is also an area where we could really really use some help. This
> > coincides with triaging the tracker, managing tasks, and communicating to
> > users.
> The tough life of the BDFL, especially if he doesn't have poor lads
> to appoint managerial positions.


> > That said, I do try to be more active in the channel lately, and to spill
> > some of my thoughts there.
> That's probably the second-best way to show you're alive.

The best being commits, I know. Working on that much more actively than I used 
to, although day job is being crazy towards year's end and has been stalling 
me for the past week or so again. Good thing vacation's coming up soon...

~ Sput
Manuel "Sputnick" Nickschas ("Sput" on Freenode)                  |  (o<
Member of the Quassel IRC Project -        |  //\
Come visit us in #quassel!                                        |  V_/_

More information about the quassel-users mailing list