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. / blc@xxxxxxxxxx -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
