Re: [fossil-users] Meta-enhancement

[David Mason]

Great! Thanks.

On 29 June 2018 at 02:24, Warren Young  wrote:

> On Jun 28, 2018, at 8:53 PM, David Mason  wrote:
> >
> > 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
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Meta-enhancement

[Warren Young]

On Jun 28, 2018, at 8:53 PM, David Mason  wrote:
> 
> 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
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Meta-enhancement

[David Mason]

Looks nice. What I meant was: what do I have to change to make it work.

Thanks  ../Dave

On 28 June 2018 at 18:33, Warren Young  wrote:

> On Jun 28, 2018, at 6:15 AM, David Mason  wrote:
> >
> > 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.
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Meta-enhancement

[Warren Young]

On Jun 28, 2018, at 6:15 AM, David Mason  wrote:
> 
> 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.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Meta-enhancement

[David Mason]

Warren, this looks great! Apologies for not knowing, but where did you make
these changes?

On 28 June 2018 at 04:11, Warren Young  wrote:

> On Jun 27, 2018, at 8:16 AM, Richard Hipp  wrote:
> >
> > 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.
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Meta-enhancement

[Andy Goth]

On 06/27/18 11:43, Richard Hipp wrote:

On 6/27/18, Andy Goth  wrote:

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

Re: [fossil-users] Meta-enhancement

[Richard Hipp]

On 6/27/18, Andy Goth  wrote:
> 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
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Meta-enhancement

[Andy Goth]

On 06/27/18 11:37, Richard Hipp wrote:

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

Re: [fossil-users] Meta-enhancement

[Richard Hipp]

On 6/27/18, David Mason  wrote:
>
> 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
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Meta-enhancement

[David Mason]

On 27 June 2018 at 11:16, Richard Hipp  wrote:

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

Re: [fossil-users] Meta-enhancement

[Richard Hipp]

On 6/27/18, Warren Young  wrote:
>
> 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
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Meta-enhancement

[Warren Young]

On Tue, Jun 26, 2018 at 10:57 PM, David Mason  wrote:

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

Re: [fossil-users] Meta-enhancement

[David Mason]

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

On 26 June 2018 at 14:52, Andy Goth  wrote:

> On 06/26/18 12:42, Richard Hipp wrote:
>
>> On 6/26/18, Andy Goth  wrote:
>>
>>> 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
>> 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 | 
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Meta-enhancement

[Andy Goth]

On 06/26/18 12:42, Richard Hipp wrote:

On 6/26/18, Andy Goth  wrote:

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

Re: [fossil-users] Meta-enhancement

[Richard Hipp]

On 6/26/18, Andy Goth  wrote:
> 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
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Meta-enhancement

[Andy Goth]

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