Fate vs Bugzilla for feature tracking

[Aaron J. Seigo]

On Friday 23 January 2009, Michael Leupold wrote:
> On Friday 23 January 2009 04:37:01 Aaron J. Seigo wrote:
> > * proper comment threading
>
> While this is currently not there it shouldn't be too hard to implement.
> There's a pending wish in bugzilla's bugtracker so I think it might be
> appreciated upstream.

great .. and yes, i think as much of this as possible should go upstream. 
preferably all of it.

> > * ability to easily mix things like screenshots right into the comments
> > areas; very important for brainstorming
>
> I agree this is useful (maybe presenting as a thumb to get a quick
> overview?).

that would work nicely, yes.

> > * ability to delete comments and close reports permanently
>
> Not sure about that. Closing bugs permanently might be useful for stubborn
> users reopening closed bugs 

and bugs opened for no other purpose than to be a dick. sorry, this is not a 
"might be" but "would have been very useful numerous times in the past 
already" feature. that's why i filed it under "must haves"

> but I'm not sure about the "deleting comments"
> part. Ideally we could keep all information but still have only the useful
> part visible.

sure, i don't care if it's archived or not. i just want to be able to remove 
comments from the report as displayed permanently.

this also isn't just about situations of abuse, either. there is the case 
where you make a comment that contains factual error. oops! in the current 
system you then have to post another comment correcting that one. threading 
would help, but even nicer would be able to just hit "Delete" or even "Edit" 
and correct that issue.

we have reports with svn commit messages that had the wrong BUG:# entry (i've 
done that a couple times myself.. i'm human like everyone else). being able to 
just delete those from the report instead of having a "oops! wrong report, 
ignore that one!" comment would be helpful.

basically, this is about improving the quality and accuracy of the 
conversation associated with a bug report.

> > * ability to view lists of reports based on user account; this would
> > allow us to use bugs.kde.org as a dev communication tool for things like
> > patches. right now, it's completely unuseful for that because all bugs go
> > into one place and so we get a mess of user, downstream and contributor
> > reports.
>
> Lists of reports based on user account are already possible.

but "user account" lacks any semantic meaning, so i can't get a list of "all 
bugs containing patches from OSVs". i don't want to see just Helio's or 
Binner's patches; i want to see *all OSV patches*.

and i shouldn't need to know that Binner is an OSV downstream, nor should i 
need to know his email address .. i should just be able to get "patch reports 
from user accounts of type $TYPE"

> Lists based on
> account categorization of course depends on implementing that feature.

exactly.

> > * ability to have developer discussion of a report in a separate thread
> > from user input. it's madenning to not be able to have peer discussions
> > without being interupted by random joe user who stops by to share his
> > brilliance.
>
> Bugzilla provides an "insider" group and private comments. I guess this

i don't care about private comments. i just want a separate thread that only 
developers/maintainers of the project can add to. everyone should be able to 
read all comments. 

> > the "probably already doable but currently clumsy":
> >
> > * ability to mark, as a project committer only!, a feature for acceptance
> > and have that feed into a feature plan report. from that report, i should
> > be able to defer features to the next release and otherwise do simple
> > feature plan managemet
>
> I think we're just not using that feature yet. Bugzilla's target milestone
> feature should be enough to implement it.

a "target milestone" as a single drop down choice would be feasible but also 
fairly limiting. marking something for acceptance should also note other items 
such as who is taking it on (can be done by Assigning the bug), the priority 
of that feature (the Priority attribute could work here, but it's pretty 
course grained at the moment), and all these attributes should be right next 
to each other. i don't want to be scrolling up and down the page to make this 
happen. 

nor should i have to remember email addresses. imho the CC and Assign To lists 
should be editable drop downs pre-populated with all accounts that are marked 
as associated to the project.

the entries in the Target listing right now are now terrifically useful 
either; the distinction between "by 4.3 freeze" and "by 4.3 release" is, for 
this particular need, academic and unuseful to me.

and yes, it's these kinds of things that add up, one on top of the other, to 
make using bugzilla order of magnitude slower that it should be for what is 
really very basic workflow issues.

> Predefined feature plan reports are indeed nice-to-have.

without them, target milesone marking is next to useless because it makes 
finding those items harder to find and therefore harder to manage. so it's not 
really a "nice-to-have" imho, it's a requirement if Target is to be seriously 
used.

you can do searches on Target, though, so feature plans could be as simple as 
a stored search with some sensible structure for the results.

> > * ability to mark, as a distro or other blessed downstream entity, items
> > as must haves along with their personal "useful by" date (for a distro
> > that would probably be the next version release date); i should then be
> > able to view these as separate reports from everything else.
>
> Not sure. After all we're having fixed release dates.

it's useful to know how our release date matches up with their "useful by" 
date when planning. how close the "useful by" date is to our next release 
determines whether or not i need to put effort into it for the next release, 
if i need to task some extraordinary efforts to it or just delay.

not knowing when downstreams could start using something makes resource 
planning a lot harder. two examples:

the network manager widget is being developer "for" 4.2, but outside of the 
main tree in response to "useful by" information from OpenSuse and others.

i made some internal changes to Plasma::Package after the 4.2 RC that i was 
going to wait until 4.3 for to accomodate a "useful by" communication from 
Fedora. this prevented some annoyances on their end for their next release.

it has been useful to plan dev based on such "useful by" dates. obviously this 
is a little harder for monolithic applications to do, and it's impossible to 
do if you don't know "useful by" dates in the first place. i manage this by 
keeping personal communication with downstreams open. that is not 
replicatable, scalable or robust, however.

> Apart from that
> adding extra marks shouldn't be hard.

this particular marking needs to be per-user, not global to the report. i need 
to know how many of what sort of user account needs this feature how badly and 
by when. that's the information that enables me to make good decisions.

having a bug marked as "Really Useful" doesn't tell me much at all.

> > * rss feeds; right now we use mailing lists and they are ok-ish but
> > clumsy
>
> Sorry, I don't understand what you mean/want the rss for.

i want to be able to follow reports or streams of reports in akregator. as an 
added bonus, this means that i can reply to them inline right there without 
opening an other window (a web browser) and get to see them right there as 
they appear in a web browser. 

i just want notifications of "this changed", be able to click on that entry in 
the list and see it in the rss reader. i don't really want an email dropped in 
my box. a rich cilent could also address this need, of course.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090123/423c3cbd/attachment.sig>