Discussion:
Meta-enhancement
(too old to reply)
Andy Goth
2018-06-26 17:07:36 UTC
Permalink
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>
Richard Hipp
2018-06-26 17:42:34 UTC
Permalink
Post by Andy Goth
A
forum might be nice, but I don't want to have to enhance Fossil just to
be able to discuss enhancing Fossil!
Initial prototypes for the forum code are already in the tree. It
just needs some more work. The recent email notification enhancements
were made in order to support ongoing Forum development.

Patience, grasshopper.
--
D. Richard Hipp
***@sqlite.org
Andy Goth
2018-06-26 17:52:21 UTC
Permalink
Post by Richard Hipp
A forum might be nice, but I don't want to have to enhance Fossil
just to be able to discuss enhancing Fossil!
Initial prototypes for the forum code are already in the tree. It
just needs some more work.
I noticed! Thank you.
Post by Richard Hipp
The recent email notification enhancements were made in order to
support ongoing Forum development.
I figured that's why you were doing it, and I thought it was very clever
to recognize that email is useful for more than just forum integration.
So even if forums end up dropped, we'll still have a major benefit for
having made the attempt.
Post by Richard Hipp
Patience, grasshopper.
Naturally. But even with forums in place, I think there's benefit to
putting the existing Fossil ticket and wiki systems back in service.
Email/forums, tickets, and wiki individually serve different goals, but
they can be used together to implement a workflow management system.
Though in a sense, wiki is the odd man out. With good email/forums and
tickets, wiki isn't really necessary, but nevertheless wiki is commonly
used as an informal replacement for email/forums and tickets.
--
Andy Goth | <andrew.m.goth/at/gmail/dot/com>
David Mason
2018-06-27 03:57:22 UTC
Permalink
It does seem a bit strange that we all sell the value of fossil partly
because it has a wiki and ticket system built in..... but then we don't eat
our own dog food.

I'm no better on my personal projects... but perhaps RSS can also play a
role here. Or if one could subscribe to the email updates for the ticket
system and forum, one could monitor what was being discussed, and click in
to join the discussion.

../Dave
Post by Andy Goth
Post by Richard Hipp
A forum might be nice, but I don't want to have to enhance Fossil
just to be able to discuss enhancing Fossil!
Initial prototypes for the forum code are already in the tree. It
just needs some more work.
I noticed! Thank you.
The recent email notification enhancements were made in order to
Post by Richard Hipp
support ongoing Forum development.
I figured that's why you were doing it, and I thought it was very clever
to recognize that email is useful for more than just forum integration. So
even if forums end up dropped, we'll still have a major benefit for having
made the attempt.
Patience, grasshopper.
Naturally. But even with forums in place, I think there's benefit to
putting the existing Fossil ticket and wiki systems back in service.
Email/forums, tickets, and wiki individually serve different goals, but
they can be used together to implement a workflow management system. Though
in a sense, wiki is the odd man out. With good email/forums and tickets,
wiki isn't really necessary, but nevertheless wiki is commonly used as an
informal replacement for email/forums and tickets.
--
Andy Goth | <andrew.m.goth/at/gmail/dot/com>
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Warren Young
2018-06-27 13:42:28 UTC
Permalink
we all sell the value of fossil partly because it has a wiki
The current wiki is great for evergreen content: information whose lifetime
is independent of that of the software being discussed. Whenever the
documentation must evolve in lockstep with the software it describes, you
should use the embedded documentation feature
<https://www.fossil-scm.org/xfer/doc/trunk/www/embeddeddoc.wiki> instead.

We could heal this dichotomy if, after saying something like "fossil up
2017-06-05", the wiki as presented by "fossil ui" would show the wiki
documents contemporaneous with that checkout. Then it wouldn't much matter
whether you chose wiki or embedded docs.

and ticket system
The problem there is spam.

With the upcoming email and forum features, that problem may be solved by
requiring an email-verified login before someone can create a ticket, so
that it is no longer necessary to have a human gatekeeper on the ticket
tracker.

I'm no better on my personal projects...
I am. ;) I use the wiki and ticket tracker on both public and private
Fossil repos.

No one's spammed my public Fossil ticket tracker yet, but as I recall, it's
set up to require a valid user login to create tickets.
Richard Hipp
2018-06-27 14:16:40 UTC
Permalink
Post by Warren Young
The problem there is spam.
Captchas and requiring moderator approval of wiki edits and new
tickets goes a long way toward fixing the spam problem.

Another more important reason why I turned off anonymous tickets is
that the signal-to-noise ratio was just too low. An overwhelming
majority of tickets were really support requests and/or new feature
requests. There were very few actual bugs reported by tickets.

If a feature request comes in via ticket, I can either leave the
ticket open for some future date when I might implement the idea, or I
can close it immediately as "not a bug". If I leave it open, then
people become alarmed at all the open bugs against Fossil. If I close
it right away, people misunderstand that as rejecting the idea.
Either way, users end up feeling unhappy.

In my experience, the mailing list is a much better mechanism for
dealing with community input. Ideas get expressed and debated, but I
am under less pressure to pick sides or to take immediate action on
marginal ideas. Hopefully the new Forum feature with email
notification might work out even better than the mailing list.
--
D. Richard Hipp
***@sqlite.org
David Mason
2018-06-27 16:10:00 UTC
Permalink
Post by Richard Hipp
If a feature request comes in via ticket, I can either leave the
ticket open for some future date when I might implement the idea, or I
can close it immediately as "not a bug". If I leave it open, then
people become alarmed at all the open bugs against Fossil. If I close
it right away, people misunderstand that as rejecting the idea.
Either way, users end up feeling unhappy.
Wouldn't it be better if feature requests didn't count as bugs. And if
tickets were marked as bugs, can't they be redefined as feature requests
(and then left open)? (I apologize for not knowing the details)

../Dave
Richard Hipp
2018-06-27 16:37:45 UTC
Permalink
Post by David Mason
Wouldn't it be better if feature requests didn't count as bugs. And if
tickets were marked as bugs, can't they be redefined as feature requests
(and then left open)?
Yes, you could do that. I encourage you to experiment with that
technique on your own projects and let us know how it goes. If you
report a positive experience, then I will consider trying it on Fossil
and SQLite.

My impression is that I would be troubled by the thousands of open
feature requests that the ticket system would be carrying around. But
perhaps that is just a personal bias that I need to overcome.
--
D. Richard Hipp
***@sqlite.org
Andy Goth
2018-06-27 16:40:39 UTC
Permalink
Post by Richard Hipp
My impression is that I would be troubled by the thousands of open
feature requests that the ticket system would be carrying around. But
perhaps that is just a personal bias that I need to overcome.
Would you be okay with me creating feature requests to track my own
Fossil development ideas, or would you prefer I keep them in wiki pages
or somewhere else?
--
Andy Goth | <andrew.m.goth/at/gmail/dot/com>
Richard Hipp
2018-06-27 16:43:35 UTC
Permalink
Post by Andy Goth
Would you be okay with me creating feature requests to track my own
Fossil development ideas, or would you prefer I keep them in wiki pages
or somewhere else?
I prefer them on this mailing list for now. What advantage do you
hope to gain from moving feature requests to tickets and/or wiki?
--
D. Richard Hipp
***@sqlite.org
Andy Goth
2018-06-27 17:07:21 UTC
Permalink
Post by Richard Hipp
Post by Andy Goth
Would you be okay with me creating feature requests to track my own
Fossil development ideas, or would you prefer I keep them in wiki pages
or somewhere else?
I prefer them on this mailing list for now. What advantage do you
hope to gain from moving feature requests to tickets and/or wiki?
I don't fully know. I'm trying to explore alternatives right now, in
this thread. That's why I started it.

My concern about putting everything in email is I have too much
accumulated to dump all at once, and I wanted a way to not lose track.
Instead my thought was to archive it all somewhere permanent then open
individual items for discussion in the order I want to talk about and
possibly implement them. Then I can later see what I've covered and
what I haven't and choose new topics, time permitting, or reconsider in
light of other developments, all the while keeping track of the thought
process. The discussion would be predominantly on this mailing list,
but it would be indexed and summarized by the ticket tracker.

Others can do the same thing and independently pick from the list of
open feature requests (also bugs, I have those to report as well) to
write/code about even if I haven't written emails about them yet.

Plus, check-ins can reference tickets quite a bit more easily than they
can reference emails, and check-ins show backreferences from tickets but
of course not from emails.

I also thought about (and wrote about) additionally having a wiki page
to group all my ideas and bug reports together, but honestly the ticket
tracker's report capability can already do that.

Returning to the wording of your original question: "moving feature
requests". I do not propose to "move" at all. Discussion would still
continue on this mailing list, same as always, and in the vast majority
of cases it's fine for the first mention of an idea to be in an email.
The ticket tracker (or wiki) wouldn't become the new, preferred place to
talk about ideas, only a means to keep track of the overall collection.
But since I have a big pile of ideas, I can't dump them all at once on
the list, so instead I'd create tickets, marked as enhancement
(sometimes bug), with general descriptions. And there they would sit
idle until someone (me) writes an email about them to the list,
whereupon discussion commences. I'd then add ticket comments linking to
the list archives. Then, should implementation occur, we include ticket
numbers in the initial branch check-ins and the merges to trunk so that
everything be cross referenced.

Thus, the ticket tracker and wiki don't get pressed into forum duty,
since email is already handling that for us. The ticket tracker would
track tickets, with discussion limited to highly technical comments
directly targeted to the implementation. The wiki would hold documents
of the sort that can be versioned independently of the project.
--
Andy Goth | <andrew.m.goth/at/gmail/dot/com>
Warren Young
2018-06-28 07:11:26 UTC
Permalink
If I leave [a feature request ticket] open, then
people become alarmed at all the open bugs against Fossil.
I solve that problem in my repositories by distinguishing “Bugs” from “Feature Requests.”

First, I rename the default “All Tickets” report to “Bugs,” making little to no change to it.

Then I create a “Wish List” report with the following SQL, which is closely related to the default report:


SELECT
CASE priority
WHEN 'Immediate' THEN '#f2dcdc'
WHEN 'High' THEN '#e8e8bd'
WHEN 'Medium' THEN '#cfe8bd'
WHEN 'Low' THEN '#cacae5'
ELSE '#c8c8c8' END as 'bgcolor',
substr(tkt_uuid,1,10) AS '#',
datetime(tkt_mtime) AS 'mtime',
status,
subsystem,
title
FROM ticket
WHERE (type='Feature Request' or type='Documentation') and status != 'Closed'
ORDER BY substr(bgcolor, 2) DESC


Finally, I replace the Tickets navbar link with “Bugs” and “Wish List” links, which each take you to the report of the same name.

Not only does this solve the expectation problem, it means we can then use the ticket system as a release planning tool:

- Immediate: features for the next release. When all such features are implemented, the upcoming release goes into beta (feature-complete) state.

- High: things we want to get to in the next release, or maybe the one after that

- Medium: feature ideas we like, but which we aren’t willing to commit to a particular release

- Low: ideas worth keeping, but which we’re not likely to ever get to. If nothing else, this prevents the same ideas from being re-filed: it says, “Yes, someone else has had this idea already, and we’re not likely to implement it; patches thoughtfully considered.”


Feature requests generally move up and down one priority level at a time, if at all. Ideally, all requests would move up towards Immediate, but in reality, many features never make it out of Medium and almost none make it out of Low.
David Mason
2018-06-28 12:15:12 UTC
Permalink
Warren, this looks great! Apologies for not knowing, but where did you make
these changes?
If I leave [a feature request ticket] open, then
people become alarmed at all the open bugs against Fossil.
I solve that problem in my repositories by distinguishing “Bugs” from
“Feature Requests.”
First, I rename the default “All Tickets” report to “Bugs,” making little
to no change to it.
Then I create a “Wish List” report with the following SQL, which is
SELECT
CASE priority
WHEN 'Immediate' THEN '#f2dcdc'
WHEN 'High' THEN '#e8e8bd'
WHEN 'Medium' THEN '#cfe8bd'
WHEN 'Low' THEN '#cacae5'
ELSE '#c8c8c8' END as 'bgcolor',
substr(tkt_uuid,1,10) AS '#',
datetime(tkt_mtime) AS 'mtime',
status,
subsystem,
title
FROM ticket
WHERE (type='Feature Request' or type='Documentation') and status != 'Closed'
ORDER BY substr(bgcolor, 2) DESC
Finally, I replace the Tickets navbar link with “Bugs” and “Wish List”
links, which each take you to the report of the same name.
Not only does this solve the expectation problem, it means we can then use
- Immediate: features for the next release. When all such features are
implemented, the upcoming release goes into beta (feature-complete) state.
- High: things we want to get to in the next release, or maybe the one after that
- Medium: feature ideas we like, but which we aren’t willing to commit to
a particular release
- Low: ideas worth keeping, but which we’re not likely to ever get to. If
nothing else, this prevents the same ideas from being re-filed: it says,
“Yes, someone else has had this idea already, and we’re not likely to
implement it; patches thoughtfully considered.”
Feature requests generally move up and down one priority level at a time,
if at all. Ideally, all requests would move up towards Immediate, but in
reality, many features never make it out of Medium and almost none make it
out of Low.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Warren Young
2018-06-28 21:33:31 UTC
Permalink
where did you make these changes?
It’s most readily seen in this repository:

https://tangentsoft.com/pidp8i

In addition to the reporting changes I previously described, there are others, mainly in Admin > Tickets > Common. For instance, my resolution_choices list includes the nonstandard “Implemented” choice, which I use instead of “Fixed” when I finish implementing a feature request ticket.

Further thoughts on this topic:

Features do sometimes jump multiple levels. For instance, an idea that was once just a good idea — “Medium” in my system — may eventually be deemed essential and thus jump straight to Immediate priority.

Features sometimes also fall multiple levels. A person filing a feature request might have what he thinks is a really hot idea (“High”) but when we later go through the release planning exercise, management may think it’s a bad idea for some reason, so it drops to Low rather than being deleted. We may add a comment on reprioritizing at this point to record who spiked the idea, so we know who has to be convinced if the idea comes back up again.

The High priority pool rarely drains, even immediately after planning the next release. We have more great ideas than time to implement them. We just hope to get to those ideas before the world changes enough that the feature ideas become worthless, in which case we need more developers: we’ve left fruit on the tree.

The Medium pool never drains until the project planners run out of good ideas, at which point it’s time to mothball the project.

If the Low pool ever drains, it probably means you’re not capturing enough of the organization’s knowledge in Fossil. After enough member turnover, the organization will forget things it should remember.

“Low” may be an idea graveyard in a private repository, but in a public repo, it is where features that the core developers are unlikely to get to land. This pool is a good place to point outside contributors, since they’re ideas worth keeping but they’re unlikely to conflict with a core developer’s plans. That’s not an exclusive characterization: Medium will have more such ideas, just with a higher risk that some core developer has his eye on it and has plans to get to it someday.

Fossil’s ticketing system is really quite flexible. There’s a good chance you don’t have to accept things you don’t like about it: the fix might be easily accomplished.
David Mason
2018-06-29 02:53:58 UTC
Permalink
Looks nice. What I meant was: what do I have to change to make it work.

Thanks ../Dave
Post by Warren Young
where did you make these changes?
https://tangentsoft.com/pidp8i
In addition to the reporting changes I previously described, there are
others, mainly in Admin > Tickets > Common. For instance, my
resolution_choices list includes the nonstandard “Implemented” choice,
which I use instead of “Fixed” when I finish implementing a feature request
ticket.
Features do sometimes jump multiple levels. For instance, an idea that
was once just a good idea — “Medium” in my system — may eventually be
deemed essential and thus jump straight to Immediate priority.
Features sometimes also fall multiple levels. A person filing a feature
request might have what he thinks is a really hot idea (“High”) but when we
later go through the release planning exercise, management may think it’s a
bad idea for some reason, so it drops to Low rather than being deleted. We
may add a comment on reprioritizing at this point to record who spiked the
idea, so we know who has to be convinced if the idea comes back up again.
The High priority pool rarely drains, even immediately after planning the
next release. We have more great ideas than time to implement them. We
just hope to get to those ideas before the world changes enough that the
we’ve left fruit on the tree.
The Medium pool never drains until the project planners run out of good
ideas, at which point it’s time to mothball the project.
If the Low pool ever drains, it probably means you’re not capturing enough
of the organization’s knowledge in Fossil. After enough member turnover,
the organization will forget things it should remember.
“Low” may be an idea graveyard in a private repository, but in a public
repo, it is where features that the core developers are unlikely to get to
land. This pool is a good place to point outside contributors, since
they’re ideas worth keeping but they’re unlikely to conflict with a core
developer’s plans. That’s not an exclusive characterization: Medium will
have more such ideas, just with a higher risk that some core developer has
his eye on it and has plans to get to it someday.
Fossil’s ticketing system is really quite flexible. There’s a good chance
you don’t have to accept things you don’t like about it: the fix might be
easily accomplished.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Warren Young
2018-06-29 05:24:24 UTC
Permalink
Post by David Mason
Looks nice. What I meant was: what do I have to change to make it work.
Clone my repository, go into Fossil UI, then navigate to Admin > Tickets. Copy as much or as little of what you see there into your Admin > Tickets sections as makes sense for your your purposes.

Then do the same for Admin > Skins. At minimum here, you’ll want my Bugs and Wish List button changes.

You need to copy from a local clone because you won’t be able to get into my repository’s Admin section via my public Fossil instance, lacking admin privileges on that instance.
David Mason
2018-06-29 13:19:01 UTC
Permalink
Great! Thanks.
Post by Warren Young
Post by David Mason
Looks nice. What I meant was: what do I have to change to make it work.
Clone my repository, go into Fossil UI, then navigate to Admin > Tickets.
Copy as much or as little of what you see there into your Admin > Tickets
sections as makes sense for your your purposes.
Then do the same for Admin > Skins. At minimum here, you’ll want my Bugs
and Wish List button changes.
You need to copy from a local clone because you won’t be able to get into
my repository’s Admin section via my public Fossil instance, lacking admin
privileges on that instance.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Loading...