I originally wanted sub-forums, which is my guess at what you mean by "category labels", but I've abandoned the idea for a bunch of reasons:

• Fossil's value proposition favors simplicity over implementing every last user wish as a hard-coded feature. There's a lot of designed-in flexibility in Fossil, where it's up to the user to customize Fossil to meet specific needs, but designed-in features carry many extra costs: development time, maintenance time, documentation, support... We need solid reasons to pay those costs.

• Fossil already works best as a per-project repository. Therefore, what are the multiple topic categories needed within that single project? If you give me an example, I can probably flip it around to make an argument that it shows you should break that repository up along the same lines.

• If you really need multiple forums for a single project, Fossil currently allows you to stand up multiple Fossil instances, one per sub-forum. This means you don't get easy cross-links, but that just takes you back to the prior argument. If you frequently need such cross-links, should you be segregating the discussions in the first place? And if you don't need such cross-links, shouldn't you be segregating the associated versioned content as well into a repo-per-project scheme?

• Dedicated bulletin board and web forum software is coming at the problem from an entirely different direction, which means they're designed with a different outlook. Their designers want their software to become your single solution for web discussions, so they provide tools for throwing everything into that single bucket. Fossil isn't trying to replace, say, vBulletin. We should expect that it will be designed differently.

Let's get concrete. I wave a magic wand and Fossil now has sub-forums; I wave it again and make you an administrator of this forum. What sub-forums would you immediately create for this project?

The closest I ever came to an answer is "users and developers", mirroring the old two mailing list split, but the old developer list wasn't really pulling its own weight, sometimes going weeks without posts. I'm happy with their functions now being merged here.

stick categories and comments to the top of the list

Isn't that just forum software attempting a poor mimicry of a wiki, which we already have?

I've just thought of another argument against having multiple forums per project: it creates uncertainty in where any given post should go.

In many online communities I've been a part of which have multiple forums, a ridiculous amount of effort goes into "You posted that in the wrong place" replies, moving posts about, writing rules saying what goes where, pointing newbies at the rules when they unknowingly violate them, etc.

You need a lot of value to outweigh those downsides.

The best argument I've ever seen for multiple forums is that the message traffic simply outstrips a single user's ability to keep up with the traffic on a single forum. Traffic usually has to get into the hundreds of messages per day before that becomes a credible argument.

If you have many users that can reasonably monitor only a subset of the messages and get everything they need out of those segregated communication channels, maybe you need multiple projects, not multiple forums, which in Fossil-land means multiple repositories.

Multiple times, I've seen a project with multiple discussion groups where almost everything ends up in the "General Discussion" category, and no one cares, because the traffic is too low to justify multiple forums. I think the site admins organize the topics that way in large part so their forum index page doesn't look empty, having only one forum. We don't have that problem here, there being no forum index page at all.

Lots of projects have both a user (or support) forum, and a developers forum. I think the problem with your simplicity argument is that we could also apply it to wiki pages - why do you need more than one wiki page per project?

What if tags were implemented in the forum?

I think experience shows that most people won't bother to tag posts properly. That then pushes you towards moderator-level functions to add new tags, retag existing posts, merge existing tags, split them, reorganize them....

What seems to have more power is strong search: Google, Spotlight, Cortana...

I don't have an informed opinion about FTS in SQLite, but if it's inadequate, I'd rather put time into making it better than augmenting it with user capabilities many won't use, shifting the burden to the mods.

I recall that FTS4 search term stemming was turned off on /forum at some point for some reason about a month ago. If that's still the case, re-enabling that would make search more useful.

There already is a search working.

As already stated by others, it's not that unusual for categories to exist in forums.

There already is a search working.

Yes, but stemming is not enabled, which means a search for "stem" on this forum turns up no results, even though it's now been used in two separate posts. You have to search either for "stemming" or "stem*".

I'm addressing your point that posts can get lost: without search stemming, they are indeed harder to find.

it's not that unusual for categories to exist in forums.

Yes, but is Fossil intending to replace vBulletin, phpBB, etc.?

I've been on many forums in the past where creating a new post is often what new people do, rather than search for existing answers.

Do you think the improvements to forum search will cause less double-posts? I don't. It's a little more excusable on a mailing list, because if I'm a new subscriber, I don't have access to previous mails. There are publicly searchable mailing lists, but still, many people write a new mail regarding their question.

Injecting...

For technical forums, I find four sub-forums are a comfortable setup.

• Help getting started (anonymous postings allowed, moderator approval required)
• Main (Project name - for both users and insiders)
• Contributions (insider technicals)
• Lounge (off topic, social chats, humour)

Others may have a wider view, perhaps more restrictive, but I find those four to be a nice balance. Three of the four sub forums require user accounts.

Cheers, Brian

Injecting...

More like "participating," to my view. You don't need to excuse yourself for that.

Help getting started (anonymous postings allowed, moderator approval required)

It would complicate Fossil's RBAC system to make permissions vary based on the sub-forum. If Fossil did get a sub-forum feature, I'd expect the current forum permissions to apply equally to all sub-forums.

If you need varying permission sets per sub-forum, that's another good reason to host them in separate Fossil repositories.

Without that distinction, I'm not seeing the difference between Help & Main in your example.

Contributions (insider technicals)

I'm involved in a project where there's a Fossil forum for developer discussions and a separate user forum hosted on different technology, but that's only because the user forum is managed by someone else, and it's years older. The reason we have a separate developer forum hosted by Fossil at all is because it's part of the software development repository, not to try and fork the project discussions into user & developer parts.

I've often seen problems from a user/developer split, in fact: the developers discuss some future direction for months or years, then the change lands in a release, then a bunch of normal users get outraged over the "sudden" change. This causes a big old flame war about how the devs went and moved everyone's cheese, while the moderates point out that we've been planning and implementing this change in public for ages.

Since the whole point of public discussion forums is to communicate and discuss, this failure of communication even though everything is nominally in public seems like a real tragedy to me.

That's not an isolated anecdote. I've seen it several times.

As long as the message volume is low enough, I say you should keep the community together so there are no missed communications.

Lounge (off topic, social chats, humour)

If the forum is hosted as part of a Fossil version control repository (e.g. a typical software project), I don't think you really want such things permanently written into its block chain.

You've clearly given prior thought to this issue. Thank you for your detailed reply.

My situation is one of working with a client base with limited "user" skills and I've been looking for a simple forum that might address the need for multiple sub-forums (as you label them) within a non-PHP world. I've looked at an ancient C language forum (years ago, name forgotten) and John Found's asm.bb but was immediately attracted to Fossil's forum when it was announced.

I've been using Fossil for a decade and have multiple repositories holding code and documentation, often separately. For my user base and their documentation needs, I've tried both versioned markdown files and wiki markdown but with limited success. The former requires knowledge of SCM's that is beyond the user base capability. The latter lacks the visibility of a forum topic list unless a front page index is labouriously maintained, as in the Fossil site's permuted index.

With clear emphasis on a non-programmer oriented function, I'm looking at the secure nature and simple setup of Fossil. It would be a dedicated forum with other functions likely disabled until user skills are better and need arises. At least initially, users would be a closed group and I'm not convinced they could handle a distributed forum so use would be centralised.

The per project repository is an incidental feature when there is only one such forum repository. The sub-forums might have titles such as "Introduction", "System Features", "Sales Support Questions", "Feature Requests", and others that might arise particular to the environment. Each sub-forum serves to encourage focused discussions in related topics.

I accept that the search bar allows retrieval of related topics but it presupposes the topic headers are structured to include a category prefix, otherwise there is risk that searches are incomplete. I would not count on my users to create consistent and useful category prefixes. And that list of acceptable prefixes would need to be stored somewhere too.

Hope this helps in your evaluation.

Chris