MaintainerGuide

Welcome to the docker-erlang-otp wiki!

This wiki document is written to be able better collaborate between multiple maintainers, and to recruit active members who has the willing to take responsibility to become a maintainer, for the sake of project health, and cover the offline scenarios, for a vacation or for family duty, it's better to have more than 1 maintainer (but not necessary to have more than 10);

There's no need for a clear definition of an active member, but here are some examples like:

1. Anyone who actively made multiple Pull Requests for a longer period, like 12 months? it's best to check from the contributors graph:
   1. https://github.com/erlang/docker-erlang-otp/graphs/contributors (the whole project history)
   2. https://github.com/erlang/docker-erlang-otp/graphs/contributors?from=2017-05 (for the history since 2017-05)
2. Anyone who actively report issues, or made positive comments, gave constructive advice; also needs to last a longer period (12 months) to show perseverance and genuine interest on improving the project

Active Members can be invited to become a maintainer, if the member also shows interest, then proper permission GitHub merge permission can be granted

Some of my advice or Best Practice about managing Issues, or PR(s):

1. Always make a PR for some period of open discussion, DO NOT directly push to master, even the person has the push permission; the discussion period could vary from a couple of hours to a couple of days
2. Wait a LGTM from another maintainer, or in the case when all others are offline or no comments, the maintainer may self merge after some certain period, like a couple of hours or a couple of days, there're no certain rules but depends on how urgent is the code needs to be merged; Build an official Docker Image is just another way of distributing software, to have the latest upstream version in 7 days is still pretty fast, if comparing many other Linux distribution, like https://packages.ubuntu.com/search?keywords=erlang ;
3. A maintainer can merge other one's PR, although if not so sure, wait a LGTM from another maintainer is still preferred
4. Delayed but fully-discussed solution is better than rushed and fast decision; Sometimes the best solution is not so obvious, it's better to be fully discussed about all possible approaches to resolve something
5. A Bump-Version only PR, which changes the version and checksum only, is ok to be fast merged.