On Aug 3, 2018, at 12:18 PM, Richard Hipp <d...@sqlite.org> wrote:
> On 8/3/18, Dan Barbarito <d...@barbarito.me> wrote:
>> Hi all, I am trying to understand why Fossil itself does not use the
>> built-in ticketing functionality. I understand that trolls + spammers may be
>> a problem, but can't ticket changes simply be approved/denied?
> I tried that.  What I found was that I was spending an inordinate
> amount of time pressing the "Reject" button on new ticket moderation
> because almost all tickets were of the form "How do I do …"

There’s nothing inherently wrong with answering tech support questions via a 
ticket tracker as opposed to a mailing list or a web forum.  A great many 
people are in fact trained to do this by their local IT departments, who 
require that every problem be reported via the local ticket tracker.

In my own public Fossil projects, I’ve found that people are preferring to post 
tickets anonymously rather than subscribe to my mailing lists and post there.  
It seems to me that we should clear obstacles from this path rather than put up 
barriers along it.

The actual problems are:

Problem 1: Web search crawlers apparently do not index Fossil tickets very 
well: I just tried a few searches for closed tickets in one of my public repos 
which should turn up just that one ticket, and couldn’t find them.

The consequence is that answering support questions via the ticket tracker is 
effectively private 1:1 support, not the distributed one-to-many form that 
allows FOSS projects to function well despite scant tech support resources.

Solution: Ensure that the “All Tickets” report is always discoverable by a web 
spider, even if /ticket is somehow unlinked from the navbar.  Ensure that the 
report’s output is easily indexed.  It looks like Fossil does not generate 
robots.txt, so that shouldn’t be a reason for this.

Problem 2: Fossil currently only announces new tickets via /timeline[.rss], so 
that the only ones likely to answer questions are those paying attention to the 
repo’s timeline, which means the burden mainly falls on those doing the 
development.  In a healthy FOSS project, much of this burden is taken up by the 
community instead, relieving core developers of dealing with it.

Solution: Fossil.next should allow a logged-in user to subscribe to certain 
timeline events, including new tickets, but not limited to it.  Some will also 
want to get an email on every checkin, for example.

Problem 3: “Tickets” in the current skin navbars is vague, so people will 
frequently misinterpret its nature and proper use.  Also problematic would be 
terms like “Issues” or “Support.”

Alternate Solution 1: Split it into “Bugs” and “Wish List” by pointing to 
appropriate default ticket table reports.  The exact terms are not important.  
What is important is that the terminology carry intent: if you are not filing a 
bug report or expressing a wish (i.e. feature request), you should be posting 

If “Forums” precede these two links on the navbar, more people will tend to 
post there first unless they specifically know they have a bug to report or a 
wish to express.

Alternate solution 2: Fossil.next should create several default sub-forums, 
including Bug Reports, Feature Requests, and Support Requests.  The “Tickets” 
navbar link should be hidden from normal users.  Users with suitably high 
capability should be able to promote a forum post to a ticket tracker entry.

> I have a really long queue right now.  I need to
> spend several days (probably) working on SQLite.  I'll get back to
> this Fossil enhancement as I am able.  Thank you for your feedback -
> it is important.  I will deal with it as soon as I can.

The other web forum technologies have a long history, with a lot of development 
behind them.  Expectations will be high, so I would expect the wish list length 
to mainly increase for quite some time yet.

I think what you have already is close to a minimum viable product.  I’m not 
sure it’s yet ready to take over for the SQLite and Fossil project mailing 
lists, but for small projects like mine, it’s probably nearly good enough to 
start using soon.
fossil-users mailing list

Reply via email to