Hello, as you probably know, my company — Freexian — has been running the commercial side of the Debian LTS project, collecting money from sponsors and dispatching it to contributors handling the security updates. This is working pretty well by now and the amount of funding is sufficient to cover the workload.
This led me to think about expanding a bit the scope of the LTS funding that Freexian is managing to answer two different needs that I identified: 1/ First, the LTS work necessarily had an impact on other Debian teams that made the project possible (security team, DSA, buildd, ftpmasters, debian-www mainly) and I wanted to be able to give back to those teams. 2/ we have always allowed paid contributors to go beyond just preparing security updates for the LTS release. They can pick tasks that improve the LTS project at large (we try to collect such tasks here: https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues) but they should not go over 25% of their allocated monthly hours so this limits their ability to tackle bigger projects and we would like to be able to tackle bigger projects that can have a meaningful impact on the LTS project and/or Debian in general. So I thought about it and I made a proposal to the paid LTS contributors that has been accepted: every month we are putting 10% of the LTS funding aside to be able to fund larger tasks/projects. We will regularly seek project proposals, review them and pay someone to implement the proposals that have been retained. We have tried to formalize a process for this in this salsa project: https://salsa.debian.org/freexian-team/project-funding https://salsa.debian.org/freexian-team/project-funding/-/blob/master/Rules-LTS.md (I'm pasting a copy of the two relevant markdown files at the end) We highly encourage the above-mentionned Debian teams to make proposals. A member of those teams can implement the project and be paid for it. Or they can decide to let someone else implement it (we expect some of the paid LTS contributors to be willing to implement such projects), and just play the reviewer role driving the person doing the work in the right direction. Contrary to Google's Summer of code and other similar projects, we put the focus on the results (and not in recruiting new volunteers), so we expect to work with experienced persons to implement the project. But if the reviewer is happy to be a mentor and spend more time, then it's OK for us too. The reviewer is not a paid position. I really want to try out something on this level but I also know that the topic is sensible so I want to get your feedback to make sure we find a good balance and make it acceptable to Debian at large (I'm not aiming at 100% acceptance, but I'd like this to be accepted just like LTS funding has become normal for most Debian developers). So I welcome your comments on this proposal. I'm really busy lately so I might not be super-reactive but I have postponed this discussion for too long already so I'm sending it out anyway (at this point we already have 13200 EUR that we can use to fund projects!). Cheers, PS: Here are the relevant files from the project-funding git repository: README.md: ---------- :warning: This document is currently in draft state. Is subject to frequent and significant revisions until it is finalized. # Project Funding This repository is used to track free software projects that Freexian is willing to fund to some extent. Freexian can fund projects for different reasons and the rules applied in each case will vary depending on the origin of the funding: * As part of its Debian LTS offering, Freexian has a budget to invest into projects that will directly or indirectly improve the Debian LTS project. Any Debian member can submit project proposals and they will all be considered. See [LTS-specific rules](Rules-LTS.md). * Freexian can also put out projects proposals on its own. In that case, they are usually justified by internal needs or customer requests. See [Freexian-specific rules](Rules-Internal.md). # Project Workflow Each project progresses through several stages. In order to ensure complete high quality work on fully vetted projects, a project must be proposed, approved, executed, and completed. ## Vocabulary * Project submitter: the person or team that submits a project proposal * Executor: the person who "executes" or "implements" the project, it's the person whose work will be funded by Freexian * Reviewer: the person who ensures that the executor completed the project and that the result is compliant to the project description. * Bid: an offer made by someone to execute a project at a given price following a given timeline * Project Managers: person(s) appointed by Freexian to handle issues and merge requests in this GitLab project. Usually Raphaël Hertzog. * Freexian manager: Raphaël Hertzog ## Project Proposal The project development process begins with the completion of a project proposal and submission of the proposal. A sample project proposal template and associated instructions for completing the sections of the project proposal can be found in the _templates/_ sub-directory. Once the proposal has been prepared and is ready for review, it should be submitted as a merge request against this project. It is usually expected that the project submitter also picks the role of either the reviewer or the executor. When acting as executor, the project proposal should come with a bid. When acting as reviewer, they should ideally be ready to review the bids to select the best one. ### Proposal Naming Convention Projects (and their associated proposals) are identified using the following pattern: > YYYY-MM-short-name.md Where, * YYYY - the 4-digit year during which the project proposal draft was submitted * MM - the 2-digit month during which the project proposal draft was submitted * short-name - a unique identifier for the project * .md - the file extension indicating that the proposal is in Markdown format When you begin drafting your proposal, you may not know the year/month of initial submission or the ordinal identifier for the project. The best time to set these values is immediately before committing the proposal to the _proposed/_ sub-directory for the first time. Only the person committing the proposal needs to be concerned with properly assigning the values. ## Project Approval Project Managers will ensure that pending project proposals are reviewed regularly (at least once in a semester), assuming that there are funds to be allocated to new projects. The review process will follow the rules associated to the funding source that the project applies to. Currently, only the LTS funding source is accepting external project submission. Depending upon the decision, the project proposal will be moved to the _accepted/_ or _refused/_ sub-directory. It can also be kept in the _proposed/_ directory, if the project proposal was good but not enough funding was available to cover all the projects. Accepted projects can go to the next step. Refused do not progress any further. ## Project Initialization To be able to start execution, each project needs both an Executor and a Reviewer. If there's no Executor, we need to find one by collecting bids and selecting one of them. If there's no Reviewer, we need to appoint one. ### Collecting Bids to Find an Executor If the project proposal did not propose anyone to execute the project, then Project Managers will open a [request for bids](https://salsa.debian.org/freexian-team/project-funding/-/issues?label_name%5B%5D=Request+for+bids) and record the issue's URL in the project file. The request for bid will be open at least 2 weeks. During that time anyone can submit a bid by filing a new issue. One may opt to file a confidential issue if they want the details of their bid to remain private. Or they can use a public issue but only send the price offer by email to raph...@freexian.com. Issue templates are provided to aid in the creation of both _Request for Bid_ and _Bid for Proposal_ issues. The rules to select the winning bid vary depending on the origin of the funding. Once the winning bid has been selected, Project Managers will label the associated issue as "Accepted" and close the other bids' issues with a "Rejected" label. ### Finding a Reviewer If the project proposal did not define any reviewer, then Freexian must appoint a reviewer. The reviewer can be a volunteer from the community or someone paid by Freexian. ## During Project Execution At the start of the project, Project Managers should create a new issue labelled with [Project management](https://salsa.debian.org/freexian-team/project-funding/-/issues?label_name%5B%5D=Project+management) should be created to host all conversations between the Executor and the Reviewer (there is a dedicated template). The URL of that issue should be added to the summary table in the project file. Depending upon the scope of the project and how long execution is planned to take, intermediary progress reports may be required. For projects exceeding 10 billable hours or spanning more than 2 weeks, progress reports are required for each 10 hours of work or every two weeks. Progress reports should be submitted through the dedicated issue. Use the [Progress Report template](templates/Progress Report.md) in this repository to assist in preparation of progress reports. If the project incurs cost on a per-hour basis (as opposed to a flat cost for the project), then approval is required from the Freexian manager before incurring any costs beyond those agreed upon in the initial proposal. ## After Project Completion Once the project is complete, a final report should be provided. As with progress reports (described above), the final report should be sent in the dedicated issue. The Reviewer will review the final report and may request additional information or clarification. If any additional work is required, the Executor will be notified. An amended final report should be submitted after the completion of any additional work. Upon acceptance of the final report, the Reviewer should submit a merge request filling the completion date in the project file and moving that file from the _accepted/_ sub-directory to the _completed/_ sub-directory. The project management issue can be closed in the same operation by adding a `Fixes #xx` instruction in the commit message. ### Invoicing and Payment Generally, projects will be paid on a flat fee basis. It is expected that large projects will be split in multiple steps, each with its own flat fee. Invoices must be addressed to Freexian (see [administrative data](https://www.freexian.com/contact/)) and sent by email to [gera...@freexian.com](mailto:gera...@freexian.com). They will be paid by wire transfer (or with Paypal if preferred). The email should include a link to the bid's issue. Rules-LTS.md ------------ # LTS specific rules Through its [Debian LTS and Debian ELTS](https://www.freexian.com/services/debian-lts.html) service offering, Freexian is funding CVE triage and security updates for the benefits of its customers and the Debian community. While this is a big achievement, we believe that we need to do more than this to ensure the long term viability of the Debian LTS project. In particular, we believe that we need to invest in infrastructure: * we want to improve existing infrastructure that we rely on, in particular when our usage has created a burden for other Debian teams in charge of those infrastructure * we want to create new infrastructure to enable new and better workflows With the agreement of all paid LTS members, we are putting aside a part of the LTS budget to be used in funding various projects. # Who can submit projects? Anyone can submit project proposals as long as they can explain how it benefits Debian LTS (even if only in the long term). We welcome, in particular, project proposals from Debian core teams that provide infrastructure that the Debian LTS project relies on. # How will project proposals be approved? Ultimately, Raphaël Hertzog (as Freexian's owner) selects which projects will be funded. But paid Debian LTS contributors will vote upon open project proposals and it is expected that the result will be respected. Depending on the outcome, a project proposal can be either: * accepted: the proposal will be funded * refused: the proposal is dropped * deferred: the proposal is kept for a future vote (this is expected for good proposals when there's not enough funding to accept them all) # Who can make bids? If the project submitter does not want to implement the project themselves, then anyone can make bids for the project. # How will the winning bid be selected? *This is still subject to internal discussion* Selecting a winning bid is a highly subjective decision. One must put into balance the experience of the executor, its relationship with Debian and the affected teams, the expected cost, the desired quality attributes, etc. Freexian will thus delegate this decision to one specific person for each project. Ideally that person is appointed when the request for bid is opened and takes the Reviewer role too. It is expected that the process somehow favors members of the teams in charge of the infrastructure/software involved in the project. Failing that, paid Debian LTS contributors would be preferred. # Who will review the work? If the project proposal does not define any reviewer, then Freexian will appoint one of the paid LTS contributors as reviewer. -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hert...@debian.org> ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
signature.asc
Description: PGP signature
