quickjs-tart

quickjs-based runtime for wallet-core logic
Log | Files | Refs | README | LICENSE

GOVERNANCE.md (7716B)


      1 <!--
      2 Copyright (C) Daniel Stenberg, <daniel@haxx.se>, et al.
      3 
      4 SPDX-License-Identifier: curl
      5 -->
      6 
      7 # Decision making in the curl project
      8 
      9 A rough guide to how we make decisions and who does what.
     10 
     11 ## BDFL
     12 
     13 This project was started by and has to some extent been pushed forward over
     14 the years with Daniel Stenberg as the driving force. It matches a standard
     15 BDFL (Benevolent Dictator For Life) style project.
     16 
     17 This setup has been used due to convenience and the fact that it has worked
     18 fine this far. It is not because someone thinks of it as a superior project
     19 leadership model. It also only works as long as Daniel manages to listen in to
     20 what the project and the general user population wants and expects from us.
     21 
     22 ## Legal entity
     23 
     24 There is no legal entity. The curl project is just a bunch of people scattered
     25 around the globe with the common goal to produce source code that creates
     26 great products. We are not part of any umbrella organization and we are not
     27 located in any specific country. We are totally independent.
     28 
     29 The copyrights in the project are owned by the individuals and organizations
     30 that wrote those parts of the code.
     31 
     32 ## Decisions
     33 
     34 The curl project is not a democracy, but everyone is entitled to state their
     35 opinion and may argue for their sake within the community.
     36 
     37 All and any changes that have been done or are done are eligible to bring up
     38 for discussion, to object to or to praise. Ideally, we find consensus for the
     39 appropriate way forward in any given situation or challenge.
     40 
     41 If there is no obvious consensus, a maintainer who's knowledgeable in the
     42 specific area takes an "executive" decision that they think is the right for
     43 the project.
     44 
     45 ## Donations
     46 
     47 Donating plain money to curl is best done to curl's [Open Collective
     48 fund](https://opencollective.com/curl). Open Collective is a US based
     49 non-profit organization that holds on to funds for us. This fund is then used
     50 for paying the curl security bug bounties, to reimburse project related
     51 expenses etc.
     52 
     53 Donations to the project can also come in the form of server hosting, providing
     54 services and paying for people to work on curl related code etc. Usually, such
     55 donations are services paid for directly by the sponsors.
     56 
     57 We grade sponsors in a few different levels and if they meet the criteria,
     58 they can be mentioned on the Sponsors page on the curl website.
     59 
     60 ## Commercial Support
     61 
     62 The curl project does not do or offer commercial support. It only hosts
     63 mailing lists, runs bug trackers etc to facilitate communication and work.
     64 
     65 However, Daniel works for wolfSSL and we offer commercial curl support there.
     66 
     67 # Key roles
     68 
     69 ## User
     70 
     71 Someone who uses or has used curl or libcurl.
     72 
     73 ## Contributor
     74 
     75 Someone who has helped the curl project, who has contributed to bring it
     76 forward. Contributing could be to provide advice, debug a problem, file a bug
     77 report, run test infrastructure or writing code etc.
     78 
     79 ## Commit author
     80 
     81 Sometimes also called 'committer'. Someone who has authored a commit in the
     82 curl source code repository. Committers are recorded as `Author` in git.
     83 
     84 ## Maintainers
     85 
     86 A maintainer in the curl project is an individual who has been given
     87 permissions to push commits to one of the git repositories.
     88 
     89 Maintainers are free to push commits to the repositories at they see fit.
     90 Maintainers are however expected to listen to feedback from users and any
     91 change that is non-trivial in size or nature *should* be brought to the
     92 project as a Pull-Request (PR) to allow others to comment/object before merge.
     93 
     94 ## Former maintainers
     95 
     96 A maintainer who stops being active in the project gets their push permissions
     97 removed at some point. We do this for security reasons but also to make sure
     98 that we always have the list of maintainers as "the team that push stuff to
     99 curl".
    100 
    101 Getting push permissions removed is not a punishment. Everyone who ever worked
    102 on maintaining curl is considered a hero, for all time hereafter.
    103 
    104 ## Security team members
    105 
    106 We have a security team. That is the team of people who are subscribed to the
    107 curl-security mailing list; the receivers of security reports from users and
    108 developers. This list of people varies over time but they are all skilled
    109 developers familiar with the curl project.
    110 
    111 The security team works best when it consists of a small set of active
    112 persons. We invite new members when the team seems to need it, and we also
    113 expect to retire security team members as they "drift off" from the project or
    114 just find themselves unable to perform their duties there.
    115 
    116 ## Core team
    117 
    118 There is a curl core team. It currently has the same set of members as the
    119 security team. It can also be reached on the security email address.
    120 
    121 The core team nominates and invites new members to the team when it sees fit.
    122 There is no open member voting or formal ways to be a candidate. Active
    123 participants in the curl project who want to join the core team can ask to
    124 join.
    125 
    126 The core team is a board of advisors. It deals with project management
    127 subjects that need confidentiality or for other reasons cannot be dealt with
    128 and discussed in the open (for example reports of code of conduct violations).
    129 Project matters should always as far as possible be discussed on open mailing
    130 lists.
    131 
    132 ## Server admins
    133 
    134 We run a web server, a mailing list and more on the curl project's primary
    135 server. That physical machine is owned and run by Haxx. Daniel is the primary
    136 admin of all things curl related server stuff, but Björn Stenberg and Linus
    137 Feltzing serve as backup admins for when Daniel is gone or unable.
    138 
    139 The primary server is paid for by Haxx. The machine is physically located in a
    140 server bunker in Stockholm Sweden, operated by the company Glesys.
    141 
    142 The website contents are served to the web via Fastly and Daniel is the
    143 primary curl contact with Fastly.
    144 
    145 ## BDFL
    146 
    147 That is Daniel.
    148 
    149 # Maintainers
    150 
    151 A curl maintainer is a project volunteer who has the authority and rights to
    152 merge changes into a git repository in the curl project.
    153 
    154 Anyone can aspire to become a curl maintainer.
    155 
    156 ### Duties
    157 
    158 There are no mandatory duties. We hope and wish that maintainers consider
    159 reviewing patches and help merging them, especially when the changes are
    160 within the area of personal expertise and experience.
    161 
    162 ### Requirements
    163 
    164 - only merge code that meets our quality and style guide requirements.
    165 - *never* merge code without doing a PR first, unless the change is "trivial"
    166 - if in doubt, ask for input/feedback from others
    167 
    168 ### Recommendations
    169 
    170 - we require two-factor authentication enabled on your GitHub account to
    171   reduce risk of malicious source code tampering
    172 - consider enabling signed git commits for additional verification of changes
    173 
    174 ### Merge advice
    175 
    176 When you are merging patches/pull requests...
    177 
    178 - make sure the commit messages follow our template
    179 - squash patch sets into a few logical commits even if the PR did not, if
    180   necessary
    181 - avoid the "merge" button on GitHub, do it "manually" instead to get full
    182   control and full audit trail (GitHub leaves out you as "Committer:")
    183 - remember to credit the reporter and the helpers.
    184 
    185 ## Who are maintainers?
    186 
    187 The [list of maintainers](https://github.com/orgs/curl/people). Be aware that
    188 the level of presence and activity in the project vary greatly between
    189 different individuals and over time.
    190 
    191 ### Become a maintainer?
    192 
    193 If you think you can help making the project better by shouldering some
    194 maintaining responsibilities, then please get in touch.
    195 
    196 You are expected to be familiar with the curl project and its ways of working.
    197 You need to have gotten a few quality patches merged as a proof of this.
    198 
    199 ### Stop being a maintainer
    200 
    201 If you (appear to) not be active in the project anymore, you may be removed as
    202 a maintainer. Thank you for your service.