Over the past several years I've been accumulating a long and growing
list of Fossil ideas, enhancement requests, and bug reports, and it's
not productive to keep them to myself, especially since it's been ages
since I've had enough free time to meaningfully contribute code. But
I've also not wanted to flood the list with every little pet project
that comes into my head, so keep my ideas to myself is what I've done.
I'm considering making a Fossil wiki page to collect it all, but the
Fossil wiki is largely inactive and not conducive to discussion. A
forum might be nice, but I don't want to have to enhance Fossil just to
be able to discuss enhancing Fossil!
It might seem the thing to do is create a bunch of tickets so each idea
can be tracked, but there haven't been any Fossil ticket changes since
the end of 2015, so clearly that's not been the preferred practice.
Instead we've done all our discussion via email and have had very little
formal development process. But were I to dump all my ideas onto the
mailing list, surely most of them would get lost. Tickets are supposed
to be the solution to that problem, except it appears we've been
ignoring them.
My next instinct is to use the Fossil wiki. Create a wiki page that
lists the original ideas, gives a summary of their current status, and
links to their threads in the mailing list archive. This gives a way to
see all ideas quickly, know where they stand, judge them in the context
of the other ideas, and drill down to the code and discussion as desired.
Reviewing the wiki page list, I see there are not many pages, and most
of them cover the same subject: ideas, enhancement requests, bugs.
Perhaps the time has come to refactor the wiki and clean up obsolete
requests and reports, instead of adding yet another page to an uncurated
pile.
And yet, keeping that wiki page up-to-date is a manual process that the
ticket tracker system is supposed to handle automatically. Furthermore,
check-ins can reference tickets more easily and stably than they can
wiki pages; just do so on at least the first check-in of each branch as
well as on check-ins/merges to trunk. Tickets are also more appropriate
than wiki pages for capturing a discussion. But email is better yet,
allowing for branching conversations, provided people make correct use
of reply so threads stay together. (A forum would be help with that
last problem, plus could more easily and permanently be linked to/from
other areas of the repository.)
Or, do both. All three, really, since I'm biased against any approach
that doesn't include email since that's where the lively discussion occurs.
The wiki page would index and summarize the ideas and provide links to
tickets. Yes, this would be kept up manually, but it would be a little
more visible than the current ticket situation. Maybe this is just a
transitional phase marking the first step in a cultural shift. We'll see.
The tickets would link to mailing list threads, as well as be linked to
by check-ins, and would track status, assignment, finer implementation
details.
The mailing list would be where all the talk happens, all the philosophy
about which ideas are worthwhile, how to make them better, who will
benefit from them, when to tackle them, who is going to handle them, how
they interact with other things, how they will end up being used in
practice, and all that free-form stuff that would clog a wiki and would
never fit in the rigid linear structure of a ticket.
--
Andy Goth | <andrew.m.goth/at/gmail/dot/com>
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
