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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
