File:  [ELWIX - Embedded LightWeight unIX -] / embedaddon / curl / docs / GOVERNANCE.md
Revision 1.1.1.1 (vendor branch): download - view: text, annotated - select for diffs - revision graph
Wed Jun 3 10:01:15 2020 UTC (4 years ago) by misho
Branches: curl, MAIN
CVS tags: v7_70_0p4, HEAD
curl

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

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>