The way I see it is this: there are a number of issues that have been traditionally hard for volunteer projects to do. There is releasing on time (or meeting other schedules), doing grunt work that is neither innovative, novel, interesting, or scratches someone itch. There are several issues like this facing us at this time. Some of them have an impact on the community, to the extent that there are entities out there who do not have the expertise, or time, or involvement to directly help address these issue, but are willing to pay to see these tasks accomplished. Third party funding (and, indeed, the funding utilization in general) is languishing in part because potential donors have no idea what the projects needs are, nor how they may marshall the funding. I would much rather Debian merely identifies areas that need work (we are in the best position to do so), and then puts the money coming in to use. However, introducing work for hire, and an employer-employee relationship into Debian is likely to be problematic, since we are not really set up to handle that well, and setting up to do so would change the nature of the project, at least in some peoples eyes. Ceding control entirely to third parties to fund what they wish leaves several things to be desired: it presupposes that these external parties with the money have the insight, or ware willing to spend the time and effort to gain such an insight, into where the funds are best directed, or whom to give the funds to. There also have been concerns that third party funds might not be directed in directions which are optimal as far as Debian's best interests are concerned -- the proposal below lets Debian decide what is up for earmarked donor contribution. What are the kinds of things that should be funded? Well, hardware for infrastructure, or hardware for that we want to get debian to support that no one has (kernel, or installer, efforts, but not just there, perhaps) is a safe, and hopefully uncontroversial. Work for hire is trickier, but there is more below in the proposal. Human nature being what it is, one needs to void even the semblance of impropriety -- so there are checks and balances to be put in place to assure the community that this is not a get rich quick scheme. So, how do we address such different goals? a) Let Debian decide on the issues that we need assistance with. i) Timely releases Forces mitigating: 1) release team is working flat out 2) adding people and training them takes time 3) there is a fair amount of churn, since people tend to burn out ii) Non free software in the kernel Forces mitigating: 1) kernel team does not have manpower to do a minimal split 2) installer/Debian CD needs work (joeyh had that done far better) iii) Infrastructure improvements iV) SELinux integration V) Localization (would love to be able to write my name as it should be written) I propose that we let anyone initiate a grant proposal, including users. Before it gets anywhere, a grant proposal would need to be fleshed out: * Explain in detail what is being proposed. This should include the details of the task, specifications of hardware, some idea of the cost, and an estimate of time needed, etc. * An explanation of what the project is going to gain from the proposal * A solid argument for why this requires funding. Hardware is easier to justify; work for hire should require convincing arguments why it can't be done by the people in the next bullet over time. (Meeting deadlines, team fully stretched, etc are some reasons that might be acceptable). This is critical; * A person to be associated with making it happen (people who would work on the hardware port, or who run the infrastructure, or who can do the work). Add in a brief note about why the person being attached is suitable; may be used in selecting one or the other, or both). * Any time based limitations (both for the task, and for the associated people's availability). [NB: The discussions Bdale and AJ had about level of funding are something that need to be interjected ehre -- funding rates may vary from locale to locale, and the project must come to some understanding about rates, and how oversight is exercised to ensure that the work is actually done -- just pay after the work is finished is one way, I guess.] Any one may attach themselves as being willing to do the work, along with their rationale, for any task. People already contributing may end up getting preference, though. Until a proposal is fleshed out, it goes nowhere. b) prioritize the task list. Prioritizing the task list could be a delegated decision; use polls, and, as uusual, there is always the GR to over ride decisions. At this point, take into account if we have someone lined up to do the task that is deemed suitable, and is available to make effective use fo any funding. I see prioritization of the tasks, and perhaps selecting amongst the volunteers associated with the task, as the most subjective decisions left. c) The top few, say, Debian's 10 most wanted features, makes it to a web page that solicits funds for the tasks. Third parties can fund some of these tasks -- their choice. At this point, they have access to all the details needed to make their decision -- what the task is, how much money it would take (partial funding?), who would be doing it, the time frame involved. So the donors get to decide what they are payig for, There is no Debian "boss" -- the prioritizing and selecting of the various workers should not be that difficult to put in place, given that we now have a requirement that asks for concrete reasons why the work can't be done on a voluntary basis anyway (I like money may not turn out to be an acceptable defense). what would it take to implement an infrastructure like that? First, there is the proposal. Proposals need to be debated, refined. Workers need to add to the proposal, signing up to do the work,m and providing time frames when available. The proposals need to be tagged as to type (hardware, infrastructure, release, installer, ports, ...); and be tagged by priority, and ranked (most wanted, high), they need to be tagged by stages (initial, concrete, has worker ).... Apart from the time frame, this seems like a a job of the BTS. Each proposal is a bug report, the we can have user tags to define how the proposal is doing, what kind of proposal it is, and how to prioritize it. We can create templates (RFC 2822, or, hey, even XML :) for proposals, for man hours required, for people signing up for work. The advantage of templates is that we can more easily compare different proposals, get a better grasp of how well fleshed out it is, and, if we use XML, an XSLT scripot can create the nice web pages from the final form. The BTS keeps all messages, it has tags, user tags, allows one to sort multiple ways through the proposals, and is all mostly written. There was this neat code for people to sign up to evaluate the summer of code projects -- which is something that can be rehashed for these proposals too. For each class of proposals, we can have domain experts signing up to be mentors (joeyh and frans pop for the installer, for example), though other people can join in in areas they feel comfortable being called upon to be experts in. Most of this stuff is already around. And if we feel like cobbling the code for this is too kludgy in the long run, we can write something better over time. Actually, all the ruby on rails people can jump in any time now, seeing how they keep telling me easy it is to create a rails based web site to help do this kinda stuff. So, we create a pseudo package for the BTS, decide on user tags to classify the projects, set up mentor teams to evaluate projects and people tasked for each project, and we are good to go. Manoj