Wiki Feature Dashboard Additional Category

[Peter Jones]

On 12/14/2009 11:45 PM, John Poelstra wrote:
> You have an interesting idea about tagging feature pages needing an
> owner.  In reality that pretty much represents all the pages in
> 'Category:FeaturePageIncomplete'  If they had an active owner or
> developer working on the feature they wouldn't be there.

As somebody who's owned a feature page put into this category, I just
don't think this is true at all.

There are a couple of reasons for this. Certainly, the cost/benefit of
working on updating the wiki, which can sometimes consume a significant
amount of time, vs that of working on the feature itself skews heavily
towards the decision to work on the feature instead of updating the page
immediately, which means the Feature page on the wiki suffers. It's also
useful, as a developer, to queue changes to the Feature page instead of
re-editing it every time anything on it changes - it's just easier to
work on one thing at a time.

The form also puts a lot of burden on whomever is developing a feature
(and maintaining the form), for several reasons, listed below.  Some of
these reasons are probably more true for people working in an RH office
than for RH remotees or non-RH contributors. To wit:

a) The form isn't especially clear - the field names are basically
   all you've got to go on, and they're not terribly descriptive. 
   It's hard to know what put in several places, and many people have
   different expectations.  If you don't get it right (and it's not
   possible to get it right) you wind up having people coming to tell
   you so on a fairly constant basis. And they'll conflict, of course.

b) There's a strong pressure to update the forms *very often*, even
   for features which it's clear will be slow to make progress.

c) There's not really a clear audience to the form. Is it for the
   general population of Fedora users? Fedora developers? FESCo? The
   Board? RH management? Clearly a feature that's submitted is queued
   for FESCo's approval, though it's still unclear as to why FESCo has
   to actually *approve* every feature, or is interested in doing so,
   especially since it's obvious to everybody that they *don't* approve
   every feature, nor would they be able to if everybody implementing a
   feature actually filled out a Feature page and submitted it. Thus
   raising item d:

d) Some member of every group I listed above thinks they're not only
   the target audience for the form, but also that if there's something
   on it they don't understand or even just don't see, they're going
   to lose their livelihood if that's not rectified *immediately*.

e) Many of the people mentioned in "d" seem to be basically unwilling
   to actually read the content of the form in order to get their
   question answered. If they think something is missing from "Benefit
   to Fedora", the odds are you'll get an email (or worse, they'll show
   up at your desk and interrupt you in real time) about the "Benefit
   to Fedora" section even if the confusion is easily solved by reading
   the "Summary" or "Detailed Description" sections.  Which brings us to:

f) There are several fields which are basically redundant. If neither
   "Summary" nor "Detailed description" adequately include at least
   some large amount of "Benefit to Fedora", then the form really just
   isn't filled in. Likewise, if "Scope", "Dependencies", and "User
   Experience" are left empty or are sparse, it's it's likely because
   the developer filling out the form thought that had been explained
   well enough already and was tired of explaining things repeatedly.

g) There are fields that don't /actually/ have a purpose. You'll get
   complaints if "Documentation" is empty, but not if you put in link
   to a pdf that's irrelevant to the actual Feature.

h) There are fields that are essentially punitive. Not every Feature
   needs a release note (though some would argue that it's the only
   reason to bother with the Feature process at all...), but if you
   don't put text there for one, you're back in email-flood land. And
   it's really there because we don't trust developers to actually
   submit things for the release notes, anyway. Yes, there's plenty of
   data to support the fact that we usually won't write release notes,
   but this isn't a very good way to fix that. It's certainly not a
   convenient place to track it - especially since you've got to put
   something in that field even before you've actually implemented the
   feature, when you basically can't possibly know what would go there.
   But if you don't put something there when you first propose the
   Feature, guess whatyour inbox looks like?

i) There's a field that's just there for people who don't understand
   wikis, AFAICT. I randomly sampled some Features in
   Category:FeatureAcceptedF11 (since that's pretty stable data at this
   point in time) to see what they said for "Comments and Discussion".
   All of them just listed a link to the Feature page's "Talk:" page.
   Surely this field isn't actually helping anybody?

As far as I can tell, a slight error on any of these counts that isn't
fixed *immediately* (i.e. in less than one day) will get you on
Category:FeaturePageIncomplete. So let's stop perpetrating the fiction
that a Feature page is in that category because nobody is maintaining it,
okay?

-- 
        Peter

When privacy is outlawed only outlaws will have privacy.
		-- Zimmermann