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. We are not part of any umbrella organization and we are not
22located in any specific country. We are totally independent.
23
24The copyrights in the project are owned by the individuals and organizations
25that wrote those parts of the code.
26
27## Decisions
28
29The curl project is not a democracy, but everyone is entitled to state their
30opinion and may argue for their sake within the community.
31
32All and any changes that have been done or will be done are eligible to bring
33up for discussion, to object to or to praise. Ideally, we find consensus for
34the appropriate way forward in any given situation or challenge.
35
36If there is no obvious consensus, a maintainer who's knowledgeable in the
37specific area will take an "executive" decision that they think is the right
38for the project.
39
40## Donations
41
42Donating plain money to curl is best done to curl's [Open Collective
43fund](https://opencollective.com/curl). Open Collective is a US based
44non-profit organization that holds on to funds for us. This fund is then used
45for paying the curl security bug bounties, to reimburse project related
46expenses etc.
47
48Donations to the project can also come in form of server hosting, providing
49services and paying for people to work on curl related code etc. Usually, such
50donations are services paid for directly by the sponsors.
51
52We grade sponsors in a few different levels and if they meet the criteria,
53they can be mentioned on the Sponsors page on the curl website.
54
55## Commercial Support
56
57The curl project does not do or offer commercial support. It only hosts
58mailing lists, runs bug trackers etc to facilitate communication and work.
59
60However, Daniel works for wolfSSL and we offer commercial curl support there.
61
62# Key roles
63
64## User
65
66Someone who uses or has used curl or libcurl.
67
68## Contributor
69
70Someone who has helped the curl project, who has contributed to bring it
71forward. Contributing could be to provide advice, debug a problem, file a bug
72report, run test infrastructure or writing code etc.
73
74## Commit author
75
76Sometimes also called 'committer'. Someone who has authored a commit in the
77curl source code repository. Committers are recorded as `Author` in git.
78
79## Maintainers
80
81A maintainer in the curl project is an individual who has been given
82permissions to push commits to one of the git repositories.
83
84Maintainers are free to push commits to the repositories at their own will.
85Maintainers are however expected to listen to feedback from users and any
86change that is non-trivial in size or nature *should* be brought to the
87project as a Pull-Request (PR) to allow others to comment/object before merge.
88
89## Former maintainers
90
91A maintainer who stops being active in the project will at some point get
92their push permissions removed. We do this for security reasons but also to
93make sure that we always have the list of maintainers as "the team that push
94stuff to curl".
95
96Getting push permissions removed is not a punishment. Everyone who ever worked
97on maintaining curl is considered a hero, for all time hereafter.
98
99## Security team members
100
101We have a security team. That's the team of people who are subscribed to the
102curl-security mailing list; the receivers of security reports from users and
103developers. This list of people will vary over time but should be skilled
104developers familiar with the curl project.
105
106The security team works best when it consists of a small set of active
107persons. We invite new members when the team seems to need it, and we also
108expect to retire security team members as they "drift off" from the project or
109just find themselves unable to perform their duties there.
110
111## Server admins
112
113We run a web server, a mailing list and more on the curl project's primary
114server. That physical machine is owned and run by Haxx. Daniel is the primary
115admin of all things curl related server stuff, but Björn Stenberg and Linus
116Feltzing serve as backup admins for when Daniel is gone or unable.
117
118The primary server is paid for by Haxx. The machine is physically located in a
119server bunker in Stockholm Sweden, operated by the company Portlane.
120
121The website contents are served to the web via Fastly and Daniel is the
122primary curl contact with Fastly.
123
124## BDFL
125
126That's Daniel.
127
128# Maintainers
129
130A curl maintainer is a project volunteer who has the authority and rights to
131merge changes into a git repository in the curl project.
132
133Anyone can aspire to become a curl maintainer.
134
135### Duties
136
137There are no mandatory duties. We hope and wish that maintainers consider
138reviewing patches and help merging them, especially when the changes are
139within the area of personal expertise and experience.
140
141### Requirements
142
143- only merge code that meets our quality and style guide requirements.
144- *never* merge code without doing a PR first, unless the change is "trivial"
145- if in doubt, ask for input/feedback from others
146
147### Recommendations
148
149- we require two-factor authentication enabled on your GitHub account to
150  reduce risk of malicious source code tampering
151- consider enabling signed git commits for additional verification of changes
152
153### Merge advice
154
155When you're merging patches/PRs...
156
157- make sure the commit messages follow our template
158- squash patch sets into a few logical commits even if the PR didn't, if
159  necessary
160- avoid the "merge" button on GitHub, do it "manually" instead to get full
161  control and full audit trail (github leaves out you as "Committer:")
162- remember to credit the reporter and the helpers!
163
164## Who are maintainers?
165
166The [list of maintainers](https://github.com/orgs/curl/people). Be aware that
167the level of presence and activity in the project vary greatly between
168different individuals and over time.
169
170### Become a maintainer?
171
172If you think you can help making the project better by shouldering some
173maintaining responsibilities, then please get in touch.
174
175You will be expected to be familiar with the curl project and its ways of
176working. You need to have gotten a few quality patches merged as a proof of
177this.
178
179### Stop being a maintainer
180
181If you (appear to) not be active in the project anymore, you may be removed as
182a maintainer. Thank you for your service!
183