To Do

• Add words about
  • only one change / bug per issue (normally)
  • one issue per PR (normally)
  • don't expect fast turnaround of issues / PRs. We work part time, unless it's an emergency we don't rush things (because rushing things == bugs & mistakes). If we ever do need to work quickly, we must be extra careful abo checking the work to spot and fix the errors we made because we did stuff too quickly

Contributing

The way that the LineageOS for microG project tries to work is that for every change:

1. The need for the change is documented in an issue, which describes what needs to change, why it needs to change, and - optionally - how it needs to change.
2. The issue will be discussed by project contributors and maintainers (by commenting on the issue), who will agree on whether the change is necessary, how it will be implemented, and who will make and test the change.
3. When the work is done and tested (in a change-specific branch), a PR )or possibly several PRs) is raised to merge the change into the master branch. The PR will describe (or link to a description of) what testing has been done, and the results of that testing.
4. If everyone (i.e. at least one of the project maintainers, and preferably not the one who did the work) is happy, the change is merged (though the merge may be delayed until the currently monthly build run is finished).

This is an idealised workflow: for a long while there was only one project maintainer and they (I) sometimes took shortcuts. (It is interesting / instructive to note that most of the big issues / problems we have had in the project, coincided with me taking those shortcuts.) So the current maintainers try to stick to the workflow when we are working on stuff together. And we definitely need all these steps if we are are working with someone which is not a project member.

So, if you think that something in one of our projects need to change, the first step is to search our projects and their issue trackers to see if a similar change has already been suggested. If it has been suggested, but was not implemented, then you will probably need to come up with some good reasons why that previous decision should change. Please also bear in mind the following, (from the front page of the Web Site & Wiki)

Project Status

The project is currently in a fairly stable state:

• we are (mostly) achieving our objective of delivering monthly builds
• the only essential work that is ongoing is to
  • monitor the delivery process, to fix any problems that may occur, and to make any changes that are needed to ensure that the problems do not recur
  • to make any changes needed when upstreams make changes. In particular, when LineageOS introduces support for a new Android version and / or drops support for older Android versions

The project is therefore - in the opinion of the currently active maintainers - essentially 'feature complete' and in 'maintenance' mode.

Having done that, if you still believe a change is needed, the next step is to create an issue in the project's issue tracker, explaining:

• what the change is;
• why it is needed;
• how it could be implemented;
• if it has been raised (and rejected) previously, why does that rejection need to change?

The project maintainers will see the issue, and respond to it, indicating how we think the issue should be handled.