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 elsewhere. 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 fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
