On 04/03/2012 08:21 AM, Peter Jones wrote:
[snip]
> We need to
make the whole process one with continuous feedback, or it's never going to
work.
So I'd expect that we don't want to specify anything all that precisely -
I'd rather you come up with an implementation plan to satisfy each point,
and then we (SA Maintainer and FESCo) decide together if it's satisfactory,
and later decide that it has or hasn't yet been met, and if not what remedial
steps should be taken.
Communication is really the piece which needs development in the
proposed guidelines. SA's tend to work quite independently so the
proposal needs to spell out a few things that get everybody
communicating at the right times and the right ways. It's probably
perfectly clear in many people's minds folks how these things should be
handled, but if we could formalize them a tiny bit it would do wonders
for filling in what's missing in the secondary promotion draft.
1. What does the SA2PA proposal need to cover? MJG's 10 criteria give a
general scope of what needs to be covered, so this is more or less done.
If I'm reading Peter's comments above correctly the guidelines should
indicate that the SA2PA proposal must be generated by the SA team (as
opposed to FESCo) and should address all 10 points.
2. How should an SA team propose to FESCo and the community that their
SA is ready to be evaluated for PA track? Is submitting a feature page
the right way to start, or a discussion on f-d-l? Whatever the right
way is I'd like to see that information added to the proposed guidelines.
3. When should the SA team make their first proposal? There is great
potential for wasted effort bringing the topic up too early or too late
in the SA's development, not to mention when in the primary release
cycle such topics should be brought up.
4. How to keep FESCo and the community informed during the process.
Presumably after #2 there will be feedback along the lines of "you need
to do more on points x, y, and z". If the answer is "FESCo will say how
to keep everybody informed" then let's have the proposal state that.
Basically, I think the guidelines MJG has put together are good
principles; they just need some procedural blanks filled in so SA teams
know how to apply them and communicate with the greater Fedora community.
--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
