1# Decision making in the curl project 2 3A rough guide to how we make decisions and who does what. 4 5## BDFL 6 7This project was started by and has to some extent been pushed forward over 8the years with Daniel Stenberg as the driving force. It matches a standard 9BDFL (Benevolent Dictator For Life) style project. 10 11This setup has been used due to convenience and the fact that is has worked 12fine this far. It is not because someone thinks of it as a superior project 13leadership model. It will also only continue working as long as Daniel manages 14to listen in to what the project and the general user population wants and 15expects from us. 16 17## Legal entity 18 19There is no legal entity. The curl project is just a bunch of people scattered 20around the globe with the common goal to produce source code that creates 21great products. 22 23The copyrights in the project are owned by the individuals and organizations 24that wrote those parts of the code. 25 26## Decisions 27 28The curl project is not a democracy, but everyone is entitled to state their 29opinion and may argue for their sake within the community. 30 31All and any changes that have been done or will be done are eligible to bring 32up for discussion, to object to or to praise. Ideally, we find consensus for 33the appropriate way forward in any given situation or challenge. 34 35If there is no obvious consensus, a maintainer who's knowledgeable in the 36specific area will take an "executive" decision that they think is the right 37for the project. 38 39## Key roles 40 41### Maintainers 42 43A maintainer in the curl project is an individual who has been given 44permissions to push commits to one of the git repositories. 45 46Maintainers are free to push commits to the repositories at their own will. 47Maintainers are however expected to listen to feedback from users and any 48change that is non-trivial in size or nature *should* be brought to the 49project as a PR to allow others to comment/object before merge. 50 51### Former maintainers 52 53A maintainer who stops being active in the project will at some point get 54their push permissions removed. We do this for security reasons but also to 55make sure that we always have the list of maintainers as "the team that push 56stuff to curl". 57 58Getting push permissions removed is not a punishment. Everyone who ever worked 59on maintaining curl is considered a hero, for all time hereafter. 60 61### Security team members 62 63We have a security team. That's the team of people who are subscribed to the 64curl-security mailing list; the receivers of security reports from users and 65developers. This list of people will vary over time but should be skilled 66developers familiar with the curl project. 67 68The security team works best when it consists of a small set of active 69persons. We invite new members when the team seems to need it, and we also 70expect to retire security team members as they "drift off" from the project or 71just find themselves unable to perform their duties there. 72 73### Server admins 74 75We run a web server, a mailing list and more on the curl project's primary 76server. That physical machine is owned and run by Haxx. Daniel is the primary 77admin of all things curl related server stuff, but Björn Stenberg and Linus 78Feltzing serve as backup admins for when Daniel is gone or unable. 79 80The primary server is paid for by Haxx. The machine is physically located in a 81server bunker in Stockholm Sweden, operated by the company Portlane. 82 83The web site contents are served to the web via Fastly and Daniel is the 84primary curl contact with Fastly. 85 86### BDFL 87 88That's Daniel. 89 90# Maintainers 91 92A curl maintainer is a project volunteer who has the authority and rights to 93merge changes into a git repository in the curl project. 94 95Anyone can aspire to become a curl maintainer. 96 97### Duties 98 99There are no mandatory duties. We hope and wish that maintainers consider 100reviewing patches and help merging them, especially when the changes are 101within the area of personal expertise and experience. 102 103### Requirements 104 105- only merge code that meets our quality and style guide requirements. 106- *never* merge code without doing a PR first, unless the change is "trivial" 107- if in doubt, ask for input/feedback from others 108 109### Recommendations 110 111- please enable 2fa on your github account to reduce risk of malicious source 112 code tampering 113- consider enabling signed git commits for additional verification of changes 114 115### Merge advice 116 117When you're merging patches/PRs... 118 119- make sure the commit messages follow our template 120- squash patch sets into a few logical commits even if the PR didn't, if 121 necessary 122- avoid the "merge" button on github, do it "manually" instead to get full 123 control and full audit trail (github leaves out you as "Committer:") 124- remember to credit the reporter and the helpers! 125 126## Who are maintainers? 127 128The [list of maintainers](https://github.com/orgs/curl/people). Be aware that 129the level of presence and activity in the project vary greatly between 130different individuals and over time. 131 132### Become a maintainer? 133 134If you think you can help making the project better by shouldering some 135maintaining responsibilities, then please get in touch. 136 137You will be expected to be familiar with the curl project and its ways of 138working. You need to have gotten a few quality patches merged as a proof of 139this. 140 141### Stop being a maintainer 142 143If you (appear to) not be active in the project anymore, you may be removed as 144a maintainer. Thank you for your service! 145