Matthias Clasen said the following on 07/09/2008 07:54 PM Pacific Time:
On Wed, 2008-07-09 at 16:33 -0700, John Poelstra wrote:
I'm all ears. What are your specific ideas for a more effective process
so it is worth all the "trouble and effort"?
We've spent a lot of time up until now trying to get to a useful
process, including the public reviews of the process we have at the
start of each release. More participation and concrete suggestions from
people like you would be greatly appreciated :)
Here are some comments on my recent experience with the feature process:
I've just 'gotten back' a ton of feature pages with the comment 'please
complete section a, b, c...' - but there is no definition anywhere of
what each section is supposed to contain, so how can I know what
'complete' means ?
Fair enough. I believe in most cases requested information was for
sections that were completely blank. Up until now I thought the section
headings were self-explanatory--I believe you are the first to raise
this point about needing definitions, which we can definitely address.
I hope people will read them.
So, I have to fly blind and put something in each section in the hope
that it passes the next time. But it feels like there is a lot of
overlap between the (undefined) topics on the feature template:
If I've already filled out the 'detailed description', why am I asked to
provide more details in the 'summary' ? And if I've already listed a ton
of packages that need changes under 'scope', whats supposed to be put in
'dependencies' ? etc...
Good point. I can see where defining the sections would help for these.
In terms of requesting more for the summary--that information gets
listed on the overal summary page for all features so I thought it would
be helpful to readers of the summary page if the summary for that
particular features was more descriptive and talked in less technical
terms.
In general, I think this whole process might be more pleasant if it felt
less like writing a paper and getting it graded and more like a
collaborative process. E.g. if instead of 'please complete the user
experience section' I got some questions back like: 'I didn't quite
understand how to turn this on, will there be a menu item ?', 'does this
also require changes to package foo ?'.
I agree that doesn't sound like fun and I apologize if that is how the
reviews have come across. I confess that in most cases I don't have the
full technical background or understanding of the feature (another
reason why FESCo reviews them) to know whether information in one
section of the form supplements another or appropriate technical issues
that should be raised. In most cases I'm just trying to do a high level
review to make sure the feature page is complete so that when FESCo
reviews them it isn't a waste of their time as it was in the past when
key sections of the form were blank and it had be discussed again at the
next meeting. The feature policy does state this as a requriement,
though I understand better now where you are coming from.
The more positive collaborative process you are suggesting--which
parties would that be between?
Thanks for your feedback
John
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
