We also do not want to replicate the ticket system which we use for detailed development but perhaps these extensions would make the forum even more perfect :-/.

One of the motivations for the recent changes, and the catalyst for it finally getting done, is to help the forum fulfill the role of bug tracker, or at least to meet the ticket system halfway. Several of Fossil's own developers (including drh and myself) have openly expressed discontent with fossil's ticket system, and we're stuck supporting it until the heat-death of the universe, but we aren't required to put new (non-bugfix) code into it.

Extend forum-statuses to include 2 or more states?

That would be the ideal, but it turns out that it's stupidly slow to query the forum based on tags like that. We recently implemented pinned/sticky posts using what would be the same approach as 2+ statuses and the /forum listing's run-time increased by by some 40x. If we can solve that, pinned posts will return and the path would be clear for an arbitrary number of status flags. The ticketing system doesn't suffer from that because it uses its own, user-customizable format for defining statuses, but the approach used there is not compatible with the forum data structures (which are set in stone, lest every older version of fossil not be able to read new ones).

The problem, IMO, stems from fossil's tags being so generic. If the data structures had type-specific, custom-fit fields for this, it could be as fast as anything else, but unwinding complex fossil tag relationships is "computationally slow". It's not clear to me how to solve this, in particular not this early in the morning.

Would a template in HTML after the Search keyword in HTML be worthwhile or should we just add it into the skin?

Good question. Next question?

That's never come up before, in all of fossil's years, even in the context of the ticket system (which now, in hindsight, surprises me).

Similarly we could extend the search pattern matching

That would, of course, require a custom parser and evaluation engine. Useful, sure, but is it worth a lot of code? (That's me being unsure, not me challenging the idea.)

So this is probably a step too far but sorting messages on fields/status/time makes some sense.

The pinned posts did precisely that - posts with that tag always sorted first - and it brought the /forum view to its knees. Our approach to marking status - as fossil artifact tags - is extremely flexible but, it turns out, it can be dog slow to untangle all of the underlying table relationships to sort through them. :/

Nobody would like to see pinned posts return more than i would, and suggestions/patches for making it performant enough to return would be welcomed. With that solved, the path for doing some of what you suggest would, unless i'm sorely mistaken (which happens now and then), be clear.

This of course may all just be adding complexity to something that is already perfect.

Sure, it adds complexity, and we're always hesitant to add any, but we also can't argue with results. So...

Noting that we will do the work

Patches would be most thoughtfully considered!

Thanks Stephan,

Thoughtful/useful comments as always and the time complexity is certainly an interesting one.

Oneliner: use /ext and libfossil to do the reporting/... and maybe put in the addition Forum/Ticket/.. extension page as a separate thing (see 4 below).

I guess this looks being special purpose so for now I'll propose :

1. Use the /ext mechanism to generate reports/etc, e.g.
2. All forum threads with me as the "@user" and Open as the status.
3. Then we can do some free form versioning
4. We've got a series of these already and we could e.g. check tickets in other repos.
5. Most importantly its independent from fossil and is a mixture if sqlite, libfossil and ...
6. Release it for anyone who cares.
7. We can of course extend the Hamburger menu via skins to access the various things so thats easy, just a wiki page describing it.
8. And of course the project homepage and procedures page then just link to /ext, so the page for Daily Routine just links to the '/ext' reports.
9. It may still be worthwhile as discussed in the initial comment to add some text/links to things like the Forum and Tickets as suggested noting some of my users could probably use some prodding on policy/procedures/meaning of forum-statuses, reviews... The text (markdown/HTML) could be kept in .fossil-settings perhaps.

Actions:

1. Setup the public repo for the /ext extensions and put a few examples in there.
2. Possibly do #4

This is mostly for info rather than comment but feel free to email on [email protected]

*