There are now so many different types of new projects and ways of presenting them and asking for resources for them that a proposal protocol (or pipeline) is now required to sort them out, and make sure that proposals come to maturity when resources will be available to look at them. Most importantly, there is an obvious annual opportunity to get some minor projects done that no one has time to do, at the Summer of Code 2007 which needs a final list of projects to be prepared in spring of each year, so students can sign up for them. The Summer of Code 2007 protocol could be a test of the basic principle of developing a lot of projects and then spinning off those that turn out to be of the right scale and difficulty in spring of each year.

At present there are several pages that try to "explain" (badly) how to propose things and follow them up:

There is already a protocol implied by these names, but it's not well documented.

There are also several historical pages that list projects or proposals or imply such projects should or must exist

There are also several categories that are either redundant or have the wrong names entirely:

There are several proposal formats or styles suggested or "required". Some pages like new project policy tell you to propose the policy "on this page" but then obviously there are none there... this is discouraging. Admittedly you don't want everyone proposing projects to the Foundation, but just making it impossible to figure out how is not the way to reduce them - you'll kill as many good as bad ones. Also now that successful summer of Code proposals were compiled by Creative Commons and many other ones are visible, it would be wise at least for any projects of the scale of Summer of Code 2007 to be in that format from the beginning, and for other projects to be presented in a cut-down version of that format, so that they can easily be bulked up or wimped down to SoC format in spring of each year.

annual events

May SoC turn

The protocol should turn over all projects on an annual basis specifically tuned to SoC timing: that is, the most important day is that day that SoC announces which projects were accepted and which were rejected.

Once that's known, the format or goals of the projects accepted must be copied by other projects; The projects rejected should be integrated into normal project channels. The Summer of Code 2007 protocol deals only with this one deadline and is unnecessary if a general proposal protocol has been implemented by that time.

Smaller projects that were first steps to larger projects or have been deemed to overlap, should be carefully rationalized and integrated with other proposals to completely refactor the proposal / project names at this point.

September student turn

Because so many free software authors are students doing projects, having a good list of projects suitable for coursework ready at the beginning of September should be the next major goal. A separate student project protocol could also be developed, although it would be redundant with the SoC work and many projects would be simply holdovers from SoC.

Feedback from course instructors might refine the terms of reference or terminology used to describe projects to remain current with academic usage for certain technical terms and etc.

January turn

Many universities use semesters and many funding institutions work on a calendar year basis. Accordingly January is the next most important time to have projects ready for major reviews. A separate proposal co-funding policy for working with other foundations and organizations might be required, but ideally the deadlines of these funders would also be integrated in the protocol.

Funding categories and "what's hot" with foundations could also be reviewed at this time.

Proposal protocol

Contents

annual events

May SoC turn

September student turn

January turn