# Code & Drop

**This is a draft, it has not been submitted nor accepted by the team and should thus be treated as what it is: an idea, a proposal, not an actual process**

The CPE team currently handles three types of requests:
- Initiatives
- Infra/Releng requests
- Upstream RFE and bug reports

Initiatives are tasks taking several weeks/months that a team of several people will focus on in order to deliver.

Infra/Releng requests are tickets submitted on the respective issue tracker asking for something to be done/fixed in the current infrastructure. It can be about a build to be untagged, a mailing list to be created, a side-tag to be created/merged. They often require some level of access which makes them open to the community but not easily achievable to newcomers who will lack access.
These are handled by the sustaining team in a workflow defined in: https://docs.fedoraproject.org/en-US/cpe/day_to_day_fedora/

Upstream RFEs and bug reports are tickets opened against the upstream project that CPE is involved with. They are dealt with differently depending on the workload and focus of the team. They can be worked on by anyone in the community without any specific level of access.

In this proposal, we would like to introduce a new type of requests: **code & drop**.

Code & Drop requests are requests that are raised by the community either by tickets, or via emails or for some just hear say at conferences.
They are basically something the community identifies as something that is needed or nice to have but that they cannot build, either because of a lack of time or a lack of expertise.

I would like to propose that the CPE team be open to work on these requests in a defined way: "code & drop".

### What is a _code & drop_ project?
The idea is that the CPE team is willing to do the initial bulk of the work to implement the idea up to a set of defined behaviors (which means the idea will have a clear definition of done (DOD)), but the team is not picking up the deployment or long term maintenance of the project.
Once the DOD is reached, the project is handed over to the person requesting it, up to them to deploy and maintain it. If there are bugs or improvements to do, they will be the ones responsible for them.

The CPE team will:
- **not** be **creating the project** itself (on whichever platform it will be), as it should be tied to the requester
- **not** be subscribed to **tickets or pull-requests** on the project.
- **not** be responding to **ping** on IRC or email about the service.
- **not** build **expertise** in the team to ensure several people are knowledgeable enough to work on the application
- **not** engage the accountability of the **entire team** on a Code & Drop project. If someone from the team decides to work on a request under the Code & Drop umbrella and if they cannot deliver because of other priorities, the CPE team will not be held accountable for working/delivering on the project.

If it happens that the project would require a new large chunk of work at some point of the future, it can always be submitted for consideration to the team via the initiative process. It will then be evaluated just like any other initiative requests.

### What qualifies for _code & drop_?
1. **Small** project, for examples: simple API, no authentication, no UI, straight forward implementation
2. **Not time sensitive** projects: i.e. the project does not need to be deployed by a certain date
3. **Independent** projects: i.e. is not the corner stone of a larger project
4. Projects **with maintainers**: i.e. a project for which one or more person are agreeing on taking responsibility for the maintenance once the initial work has been done
5. **Experimental** projects: i.e. projects that are meant to be Proof Of Concept (POC) or short-lived

If you believe your idea doesn't satisfy any of the first three points above, you likely want to look at the initiative process.

> https://pagure.io/fedora-infrastructure/issue/6572 is an example of an idea/project that could fit this framework:

### How to submit _code & drop_ idea?

We still do not want people to be pinged directly as it introduces a single point of failure to your request. If you have an idea that you believe would be good for the _code & drop_ framework, simply open a ticket with it, mentionning that you accept that this idea be approached under this framework.

If someone is interested in the idea, they will comment on the ticket and you will be able to engage to determine what is the exact outcome you are looking for and at which point you will pick up the maintenance of the code.

Once an agreement is found between all parties, the ticket will be assigned to the person working on it, allowing to see who is working on what.

### What's in it for the CPE team?

So why would the CPE team accept these ideas/projects?

There are a few reasons for us to do this:
- **Help the community without impact on the long term**: In the past the team has often seen itself as the team that works on things needed/wanted in the community that no-one has the time or expertise to do. This however has led to a situation where a team of ~20 people was maintaining over 100 services. For the team's own health as well as for the long term maintainibility of the projects, the team gave itself a [mission statement](https://docs.fedoraproject.org/en-US/cpe/#_our_responsibilities) allowing to bound its work to a specific area of the project.
This has allowed the team to reduce the number of applications maintained as well as a filter to use on requests coming in.
However, there are still requests coming from the community for which CPE has the expertise and can take little time, the team can just not commit to the long term maintenance of these projects.
The Code & Drop requests are thus a way to answer a need identified in the community without committing to the long term maintenance.

- **Learning opportunities**: These requests are also opportunities for the team to investigate new programming languages, new frameworks which, in agreement with the requester(s) could be used. For example, a small API could be written in rust or golang, allowing the team to upskill in frameworks and languages without adding to the CPE sysadmins the costs of running something that they are not familiar with (since the running and maintenance will be up to the requester(s)).

- **Fun/Interesting side work**: One of the reasons for why these request should not be time sensitive is that they will be worked on by one or more team member on the side. They should be viewed as fun or interesting to do but they will not be the top priority of the people working on them. If something comes up in their main priority, it is expected that team members stop working on code & drop projects to focus on their main project/priority.