From de5fb5fef98f2d0d734e13c08c40dfb75df76ec4 Mon Sep 17 00:00:00 2001 From: Jean Burellier Date: Thu, 29 Feb 2024 21:58:34 +0100 Subject: [PATCH] chore: move all documentations and charters --- charters/Charter.md | 92 ++++++++++++++++ charters/Code-Of-Conduct.md | 139 ++++++++++++++++++++++++ charters/Collaborator-Guide.md | 51 +++++++++ charters/Contributing.md | 160 ++++++++++++++++++++++++++++ charters/Readme-Guide.md | 125 ++++++++++++++++++++++ charters/Release-Process.md | 186 +++++++++++++++++++++++++++++++++ charters/Security.md | 46 ++++++++ charters/Triager-Guide.md | 63 +++++++++++ 8 files changed, 862 insertions(+) create mode 100644 charters/Charter.md create mode 100644 charters/Code-Of-Conduct.md create mode 100644 charters/Collaborator-Guide.md create mode 100644 charters/Contributing.md create mode 100644 charters/Readme-Guide.md create mode 100644 charters/Release-Process.md create mode 100644 charters/Security.md create mode 100644 charters/Triager-Guide.md diff --git a/charters/Charter.md b/charters/Charter.md new file mode 100644 index 0000000..a906e52 --- /dev/null +++ b/charters/Charter.md @@ -0,0 +1,92 @@ +# Express Charter + +## Section 0: Guiding Principles + +The Express project is part of the OpenJS Foundation which operates +transparently, openly, collaboratively, and ethically. +Project proposals, timelines, and status must not merely be open, but +also easily visible to outsiders. + +## Section 1: Scope + +Express is a HTTP web server framework with a simple and expressive API +which is highly aligned with Node.js core. We aim to be the best in +class for writing performant, spec compliant, and powerful web servers +in Node.js. As one of the oldest and most popular web frameworks in +the ecosystem, we have an important place for new users and experts +alike. + +### 1.1: In-scope + +Express is made of many modules spread between three GitHub Orgs: + +- [expressjs](http://github.com/expressjs/): Top level middleware and + libraries +- [pillarjs](http://github.com/pillarjs/): Components which make up + Express but can also be used for other web frameworks +- [jshttp](http://github.com/jshttp/): Low level HTTP libraries + +### 1.2: Out-of-Scope + +Section Intentionally Left Blank + +## Section 2: Relationship with OpenJS Foundation CPC. + +Technical leadership for the projects within the OpenJS Foundation is +delegated to the projects through their project charters by the OpenJS +Cross Project Council (CPC). In the case of the Express project, it is +delegated to the Express Technical Committee ("TC"). + +This Technical Committee is in charge of both the day-to-day operations +of the project, as well as its technical management. This charter can +be amended by the TC requiring at least two approvals and a minimum two +week comment period for other TC members or CPC members to object. Any +changes the CPC wishes to propose will be considered a priority but +will follow the same process. + +### 2.1 Other Formal Project Relationships + +Section Intentionally Left Blank + +## Section 3: Express Governing Body + +The Express project is managed by the Technical Committee ("TC"). +Members can be added to the TC at any time. Any committer can nominate +another committer to the TC and the TC uses its standard consensus +seeking process to evaluate whether or not to add this new member. +Members who do not participate consistently at the level of a majority +of the other members are expected to resign. + +## Section 4: Roles & Responsibilities + +The Express TC manages all aspects of both the technical and community +parts of the project. Members of the TC should attend the regular +meetings when possible, and be available for discussion of time +sensitive or important issues. + +### Section 4.1 Project Operations & Management + +Section Intentionally Left Blank + +### Section 4.2: Decision-making, Voting, and/or Elections + +The Express TC uses a "consensus seeking" process for issues that are +escalated to the TC. The group tries to find a resolution that has no +open objections among TC members. If a consensus cannot be reached +that has no objections then a majority wins vote is called. It is also +expected that the majority of decisions made by the TC are via a +consensus seeking process and that voting is only used as a last-resort. + +Resolution may involve returning the issue to committers with +suggestions on how to move forward towards a consensus. It is not +expected that a meeting of the TC will resolve all issues on its +agenda during that meeting and may prefer to continue the discussion +happening among the committers. + +### Section 4.3: Other Project Roles + +Section Intentionally Left Blank + +## Section 5: Definitions + +Section Intentionally Left Blank diff --git a/charters/Code-Of-Conduct.md b/charters/Code-Of-Conduct.md new file mode 100644 index 0000000..bbb8996 --- /dev/null +++ b/charters/Code-Of-Conduct.md @@ -0,0 +1,139 @@ +# Contributor Covenant Code of Conduct + +As a member of the Open JS Foundation, Express has adopted the +[Contributor Covenant 2.0][cc-20-doc]. + +If an issue arises and you cannot resolve it directly with the parties +involved, you can report it to the Express project TC through the following +email: express-coc@lists.openjsf.org + +In addition, the OpenJS Foundation maintains a Code of Conduct Panel (CoCP). +This is a foundation-wide team established to manage escalation when a reporter +believes that a report to a member project or the CPC has not been properly +handled. In order to escalate to the CoCP send an email to +coc-escalation@lists.openjsf.org. + +## Our Pledge + +We as members, contributors, and leaders pledge to make participation in our +community a harassment-free experience for everyone, regardless of age, body +size, visible or invisible disability, ethnicity, sex characteristics, gender +identity and expression, level of experience, education, socio-economic status, +nationality, personal appearance, race, religion, or sexual identity and +orientation. + +We pledge to act and interact in ways that contribute to an open, welcoming, +diverse, inclusive, and healthy community. + +## Our Standards + +Examples of behavior that contributes to a positive environment for our +community include: + +* Demonstrating empathy and kindness toward other people +* Being respectful of differing opinions, viewpoints, and experiences +* Giving and gracefully accepting constructive feedback +* Accepting responsibility and apologizing to those affected by our mistakes, + and learning from the experience +* Focusing on what is best not just for us as individuals, but for the overall + community + +Examples of unacceptable behavior include: + +* The use of sexualized language or imagery, and sexual attention or advances + of any kind +* Trolling, insulting or derogatory comments, and personal or political attacks +* Public or private harassment +* Publishing others' private information, such as a physical or email address, + without their explicit permission +* Other conduct which could reasonably be considered inappropriate in a + professional setting + +## Enforcement Responsibilities + +Community leaders are responsible for clarifying and enforcing our standards of +acceptable behavior and will take appropriate and fair corrective action in +response to any behavior that they deem inappropriate, threatening, offensive, +or harmful. + +Community leaders have the right and responsibility to remove, edit, or reject +comments, commits, code, wiki edits, issues, and other contributions that are +not aligned to this Code of Conduct, and will communicate reasons for +moderation decisions when appropriate. + +## Scope + +This Code of Conduct applies within all community spaces, and also applies when +an individual is officially representing the community in public spaces. +Examples of representing our community include using an official e-mail +address, posting via an official social media account, or acting as an +appointed representative at an online or offline event. + +## Enforcement + +Instances of abusive, harassing, or otherwise unacceptable behavior may be +reported to the community leaders responsible for enforcement at +express-coc@lists.openjsf.org. All complaints will be reviewed and +investigated promptly and fairly. + +All community leaders are obligated to respect the privacy and security of the +reporter of any incident. + +## Enforcement Guidelines + +Community leaders will follow these Community Impact Guidelines in determining +the consequences for any action they deem in violation of this Code of Conduct: + +### 1. Correction + +**Community Impact**: Use of inappropriate language or other behavior deemed +unprofessional or unwelcome in the community. + +**Consequence**: A private, written warning from community leaders, providing +clarity around the nature of the violation and an explanation of why the +behavior was inappropriate. A public apology may be requested. + +### 2. Warning + +**Community Impact**: A violation through a single incident or series of +actions. + +**Consequence**: A warning with consequences for continued behavior. No +interaction with the people involved, including unsolicited interaction with +those enforcing the Code of Conduct, for a specified period of time. This +includes avoiding interactions in community spaces as well as external channels +like social media. Violating these terms may lead to a temporary or permanent +ban. + +### 3. Temporary Ban + +**Community Impact**: A serious violation of community standards, including +sustained inappropriate behavior. + +**Consequence**: A temporary ban from any sort of interaction or public +communication with the community for a specified period of time. No public or +private interaction with the people involved, including unsolicited +interaction with those enforcing the Code of Conduct, is allowed during this +period. Violating these terms may lead to a permanent ban. + +### 4. Permanent Ban + +**Community Impact**: Demonstrating a pattern of violation of community +standards, including sustained inappropriate behavior, harassment of an +individual, or aggression toward or disparagement of classes of individuals. + +**Consequence**: A permanent ban from any sort of public interaction within the +project community. + +## Attribution + +This Code of Conduct is adapted from the [Contributor Covenant, version 2.0](cc-20-doc). + +Community Impact Guidelines were inspired by +[Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity). + +[cc-20-doc]: https://www.contributor-covenant.org/version/2/0/code_of_conduct/ + +For answers to common questions about this code of conduct, see the FAQ at +https://www.contributor-covenant.org/faq. Translations are available at +https://www.contributor-covenant.org/translations. diff --git a/charters/Collaborator-Guide.md b/charters/Collaborator-Guide.md new file mode 100644 index 0000000..3c73307 --- /dev/null +++ b/charters/Collaborator-Guide.md @@ -0,0 +1,51 @@ +# Express Collaborator Guide + +## Website Issues + +Open issues for the expressjs.com website in https://github.com/expressjs/expressjs.com. + +## PRs and Code contributions + +* Tests must pass. +* Follow the [JavaScript Standard Style](http://standardjs.com/) and `npm run lint`. +* If you fix a bug, add a test. + +## Branches + +Use the `master` branch for bug fixes or minor work that is intended for the +current release stream. + +Use the correspondingly named branch, e.g. `5.0`, for anything intended for +a future release of Express. + +## Steps for contributing + +1. [Create an issue](https://github.com/expressjs/express/issues/new) for the + bug you want to fix or the feature that you want to add. +2. Create your own [fork](https://github.com/expressjs/express) on GitHub, then + checkout your fork. +3. Write your code in your local copy. It's good practice to create a branch for + each new issue you work on, although not compulsory. +4. To run the test suite, first install the dependencies by running `npm install`, + then run `npm test`. +5. Ensure your code is linted by running `npm run lint` -- fix any issue you + see listed. +6. If the tests pass, you can commit your changes to your fork and then create + a pull request from there. Make sure to reference your issue from the pull + request comments by including the issue number e.g. `#123`. + +## Issues which are questions + +We will typically close any vague issues or questions that are specific to some +app you are writing. Please double check the docs and other references before +being trigger happy with posting a question issue. + +Things that will help get your question issue looked at: + +* Full and runnable JS code. +* Clear description of the problem or unexpected behavior. +* Clear description of the expected result. +* Steps you have taken to debug it yourself. + +If you post a question and do not outline the above items or make it easy for +us to understand and reproduce your issue, it will be closed. diff --git a/charters/Contributing.md b/charters/Contributing.md new file mode 100644 index 0000000..dfe5f13 --- /dev/null +++ b/charters/Contributing.md @@ -0,0 +1,160 @@ +# Express.js Community Contributing Guide 1.0 + +The goal of this document is to create a contribution process that: + +* Encourages new contributions. +* Encourages contributors to remain involved. +* Avoids unnecessary processes and bureaucracy whenever possible. +* Creates a transparent decision making process that makes it clear how +contributors can be involved in decision making. + +## Vocabulary + +* A **Contributor** is any individual creating or commenting on an issue or pull request. +* A **Committer** is a subset of contributors who have been given write access to the repository. +* A **Project Captain** is the lead maintainer of a repository. +* A **TC (Technical Committee)** is a group of committers representing the required technical +expertise to resolve rare disputes. +* A **Triager** is a subset of contributors who have been given triage access to the repository. + +## Logging Issues + +Log an issue for any question or problem you might have. When in doubt, log an issue, and +any additional policies about what to include will be provided in the responses. The only +exception is security disclosures which should be sent privately. + +Committers may direct you to another repository, ask for additional clarifications, and +add appropriate metadata before the issue is addressed. + +Please be courteous and respectful. Every participant is expected to follow the +project's Code of Conduct. + +## Contributions + +Any change to resources in this repository must be through pull requests. This applies to all changes +to documentation, code, binary files, etc. Even long term committers and TC members must use +pull requests. + +No pull request can be merged without being reviewed. + +For non-trivial contributions, pull requests should sit for at least 36 hours to ensure that +contributors in other timezones have time to review. Consideration should also be given to +weekends and other holiday periods to ensure active committers all have reasonable time to +become involved in the discussion and review process if they wish. + +The default for each contribution is that it is accepted once no committer has an objection. +During a review, committers may also request that a specific contributor who is most versed in a +particular area gives a "LGTM" before the PR can be merged. There is no additional "sign off" +process for contributions to land. Once all issues brought by committers are addressed it can +be landed by any committer. + +In the case of an objection being raised in a pull request by another committer, all involved +committers should seek to arrive at a consensus by way of addressing concerns being expressed +by discussion, compromise on the proposed change, or withdrawal of the proposed change. + +If a contribution is controversial and committers cannot agree about how to get it to land +or if it should land then it should be escalated to the TC. TC members should regularly +discuss pending contributions in order to find a resolution. It is expected that only a +small minority of issues be brought to the TC for resolution and that discussion and +compromise among committers be the default resolution mechanism. + +## Becoming a Triager + +Anyone can become a triager! Read more about the process of being a triager in +[the triage process document](Triager-Guide.md). + +[Open an issue in `expressjs/express` repo](https://github.com/expressjs/express/issues/new) +to request the triage role. State that you have read and agree to the +[Code of Conduct](Code-Of-Conduct.md) and details of the role. + +Here is an example issue content you can copy and paste: + +``` +Title: Request triager role for + +I have read and understood the project's Code of Conduct. +I also have read and understood the process and best practices around Express triaging. + +I request for a triager role for the following GitHub organizations: + +jshttp +pillarjs +express +``` + +Once you have opened your issue, a member of the TC will add you to the `triage` team in +the organizations requested. They will then close the issue. + +Happy triaging! + +## Becoming a Committer + +All contributors who land a non-trivial contribution should be on-boarded in a timely manner, +and added as a committer, and be given write access to the repository. + +Committers are expected to follow this policy and continue to send pull requests, go through +proper review, and have other committers merge their pull requests. + +## TC Process + +The TC uses a "consensus seeking" process for issues that are escalated to the TC. +The group tries to find a resolution that has no open objections among TC members. +If a consensus cannot be reached that has no objections then a majority wins vote +is called. It is also expected that the majority of decisions made by the TC are via +a consensus seeking process and that voting is only used as a last-resort. + +Resolution may involve returning the issue to project captains with suggestions on +how to move forward towards a consensus. It is not expected that a meeting of the TC +will resolve all issues on its agenda during that meeting and may prefer to continue +the discussion happening among the project captains. + +Members can be added to the TC at any time. Any TC member can nominate another committer +to the TC and the TC uses its standard consensus seeking process to evaluate whether or +not to add this new member. The TC will consist of a minimum of 3 active members and a +maximum of 10. If the TC should drop below 5 members the active TC members should nominate +someone new. If a TC member is stepping down, they are encouraged (but not required) to +nominate someone to take their place. + +TC members will be added as admin's on the Github orgs, npm orgs, and other resources as +necessary to be effective in the role. + +To remain "active" a TC member should have participation within the last 6 months and miss +no more than three consecutive TC meetings. Members who do not meet this are expected to step down. +If A TC member does not step down, an issue can be opened in the discussions repo to move them +to inactive status. TC members who step down or are removed due to inactivity will be moved +into inactive status. + +Inactive status members can become active members by self nomination if the TC is not already +larger than the maximum of 10. They will also be given preference if, while at max size, an +active member steps down. + +## Project Captains + +The Express TC can designate captains for individual projects/repos in the +organizations. These captains are responsible for being the primary +day-to-day maintainers of the repo on a technical and community front. +Repo captains are empowered with repo ownership and package publication rights. +When there are conflicts, especially on topics that effect the Express project +at large, captains are responsible to raise it up to the TC and drive +those conflicts to resolution. Captains are also responsible for making sure +community members follow the community guidelines, maintaining the repo +and the published package, as well as in providing user support. + +Like TC members, Repo captains are a subset of committers. + +To become a captain for a project the candidate is expected to participate in that +project for at least 6 months as a committer prior to the request. They should have +helped with code contributions as well as triaging issues. They are also required to +have 2FA enabled on both their GitHub and npm accounts. Any TC member or existing +captain on the repo can nominate another committer to the captain role, submit a PR to +this doc, under `Current Project Captains` section (maintaining the sort order) with +the project, their GitHub handle and npm username (if different). The PR will require +at least 2 approvals from TC members and 2 weeks hold time to allow for comment and/or +dissent. When the PR is merged, a TC member will add them to the proper GitHub/npm groups. + +### Current Project Captains + +- `expressjs.com`: @crandmck +- `multer`: @LinusU +- `path-to-regexp`: @blakeembrey +- `router`: @dougwilson diff --git a/charters/Readme-Guide.md b/charters/Readme-Guide.md new file mode 100644 index 0000000..34d4648 --- /dev/null +++ b/charters/Readme-Guide.md @@ -0,0 +1,125 @@ +# README guidelines + +Every module in the expressjs, pillarjs, and jshttp organizations should have +a README file named `README.md`. The purpose of the README is to: + +- Explain the purpose of the module and how to use it. +- Act as a landing page (both on GitHub and npmjs.com) for the module to help + people find it via search. Middleware module READMEs are also incorporated + into https://expressjs.com/en/resources/middleware.html. +- Encourage community contributions and participation. + +Use the [README template](https://github.com/expressjs/express/wiki/README-template) +to quickly create a new README file. + +## Top-level items + +**Badges** (optional): At the very top (with no subheading), include any +applicable badges, such as npm version/downloads, build status, test coverage, +and so on. Badges should resolve properly (not display a broken image). + +Possible badges include: +- npm version: `[![NPM Version][npm-image]][npm-url]` +- npm downloads: `[![NPM Downloads][downloads-image]][downloads-url]` +- Build status: `[![Build Status][travis-image]][travis-url]` +- Test coverage: `[![Test Coverage][coveralls-image]][coveralls-url]` +- Tips: `[![Gratipay][gratipay-image]][gratipay-url]` + +**Summary**: Following badges, provide a one- or two-sentence description of +what the module does. This should be the same as the npmjs.org blurb (which +comes from the description property of `package.json`). Since npm doesn't +handle markdown for the blurb, avoid using markdown in the summary sentence. + +**TOC** (Optional): For longer READMEs, provide a table of contents that has +a relative link to each section. A tool such as +[doctoc](https://www.npmjs.com/package/doctoc) makes it very easy to generate +a TOC. + +## Overview + +Optionally, include a section of one or two paragraphs with more high-level +information on what the module does, what problems it solves, why one would +use it and how. Don't just repeat what's in the summary. + +## Installation + +Required. This section is typically just: + +```sh +$ npm install module-name +``` + +But include any other steps or requirements. + +NOTE: Use the `sh` code block to make the shell command display properly on +the website. + +## Basic use + +- Provide a general description of how to use the module with code sample. + Include any important caveats or restrictions. +- Explain the most common use cases. +- Optional: a simple "hello world" type example (where applicable). This + example is in addition to the more comprehensive [example section](#examples) + later. + +## API + +Provide complete API documentation. + +Formatting conventions: Each function is listed in a 3rd-level heading (`###`), +like this: + +``` +### Function_name(arg, options [, optional_arg] ... ) +``` + +**Options objects** + +For arguments that are objects (for example, options object), describe the +properties in a table, as follows. This matches the formatting used in the +[Express API docs](https://expressjs.com/en/4x/api.html). + +|Property | Description | Type | Default| +|----------|-----------|------------|-------------| +|Name of the property in `monospace`. | Brief description | String, Number, Boolean, etc. | If applicable.| + +If all the properties are required (i.e. there are no defaults), then you +can omit the default column. + +Instead of very lengthy descriptions, link out to subsequent paragraphs for +more detailed explanation of specific cases (e.g. "When this property is set +to 'foobar', xyz happens; see <link to following section >.) + +If there are options properties that are themselves options, use additional +tables. See [`trust proxy` and `etag` properties](https://expressjs.com/en/4x/api.html#app.settings.table). + +## Examples + +Every README should have at least one example; ideally more. For code samples, +be sure to use the `js` code block, for proper display in the website, e.g.: + +```js +var csurf = require('csurf') +... +``` + +## Tests + +What tests are included. + +How to run them. + +The convention for running tests is `npm test`. All our projects should follow +this convention. + +## Contributors + +Names of module "owners" (lead developers) and other developers who have +contributed. + +## License + +Link to the license, with a short description of what it is, e.g. "MIT" or +whatever. Ideally, avoid putting the license text directly in the README; link +to it instead. diff --git a/charters/Release-Process.md b/charters/Release-Process.md new file mode 100644 index 0000000..ae74097 --- /dev/null +++ b/charters/Release-Process.md @@ -0,0 +1,186 @@ +# Express Release Process + +This document contains the technical aspects of the Express release process. The +intended audience is those who have been authorized by the Express Technical +Committee (TC) to create, promote and sign official release builds for Express, +as npm packages hosted on https://npmjs.com/package/express. + +## Who can make releases? + +Release authorization is given by the Express TC. Once authorized, an individual +must have the following access permissions: + +### 1. Github release access + +The individual making the release will need to be a member of the +expressjs/express team with Write permission level so they are able to tag the +release commit and push changes to the expressjs/express repository +(see Steps 4 and 5). + +### 2. npmjs.com release access + +The individual making the release will need to be made an owner on the +`express` package on npmjs.com so they are able to publish the release +(see Step 6). + +## How to publish a release + +Before publishing, the following preconditions should be met: + +- A release proposal issue or tracking pull request (see "Proposal branch" + below) will exist documenting: + - the proposed changes + - the type of release: patch, minor or major + - the version number (according to semantic versioning - http://semver.org) +- The proposed changes should be complete. + +There are two main release flows: patch and non-patch. + +The patch flow is for making **patch releases**. As per semantic versioning, +patch releases are for simple changes, eg: typo fixes, patch dependency updates, +and simple/low-risk bug fixes. Every other type of change is made via the +non-patch flow. + +### Branch terminology + +"Master branch" + +- There is a branch in git used for the current major version of Express, named + `master`. +- This branch contains the completed commits for the next patch release of the + current major version. +- Releases for the current major version are published from this branch. + +"Version branch" + +- For any given major version of Express (current, previous or next) there is + a branch in git for that release named `.x` (eg: `4.x`). +- This branch points to the commit of the latest tag for the given major version. + +"Release branch" + +- For any given major version of Express, there is a branch used for publishing + releases. +- For the current major version of Express, the release branch is the + "Master branch" named `master`. +- For all other major versions of Express, the release branch is the + "Version branch" named `.x`. + +"Proposal branch" + +- A branch in git representing a proposed new release of Express. This can be a + minor or major release, named `.0` for a major release, + `.` for a minor release. +- A tracking pull request should exist to document the proposed release, + targeted at the appropriate release branch. Prior to opening the tracking + pull request the content of the release may have be discussed in an issue. +- This branch contains the commits accepted so far that implement the proposal + in the tracking pull request. + +### Patch flow + +In the patch flow, simple changes are committed to the release branch which +acts as an ever-present branch for the next patch release of the associated +major version of Express. + +The release branch is usually kept in a state where it is ready to release. +Releases are made when sufficient time or change has been made to warrant it. +This is usually proposed and decided using a github issue. + +### Non-patch flow + +In the non-patch flow, changes are committed to a temporary proposal branch +created specifically for that release proposal. The branch is based on the +most recent release of the major version of Express that the release targets. + +Releases are made when all the changes on a proposal branch are complete and +approved. This is done by merging the proposal branch into the release branch +(using a fast-forward merge), tagging it with the new version number and +publishing the release package to npmjs.com. + +### Flow + +Below is a detailed description of the steps to publish a release. + +#### Step 1. Check the release is ready to publish + +Check any relevant information to ensure the release is ready, eg: any +milestone, label, issue or tracking pull request for the release. The release +is ready when all proposed code, tests and documentation updates are complete +(either merged, closed or re-targeted to another release). + +#### Step 2. (Non-patch flow only) Merge the proposal branch into the release branch + +In the patch flow: skip this step. + +In the non-patch flow: +```sh +$ git checkout +$ git merge --ff-only +``` + + - see "Release branch" of "Branches" above. + - see "Proposal branch" of "Non-patch flow" above. + +**NOTE:** You may need to rebase the proposal branch to allow a fast-forward + merge. Using a fast-forward merge keeps the history clean as it does + not introduce merge commits. + +### Step 3. Update the History.md and package.json to the new version number + +The changes so far for the release should already be documented under the +"unreleased" section at the top of the History.md file, as per the usual +development practice. Change "unreleased" to the new release version / date. +Example diff fragment: + +```diff +-unreleased +-========== ++4.13.3 / 2015-08-02 ++=================== +``` + +The version property in the package.json should already contain the version of +the previous release. Change it to the new release version. + +Commit these changes together under a single commit with the message set to +the new release version (eg: `4.13.3`): + +```sh +$ git checkout +<..edit files..> +$ git add History.md package.json +$ git commit -m '' +``` + +### Step 4. Identify and tag the release commit with the new release version + +Create a lightweight tag (rather than an annotated tag) named after the new +release version (eg: `4.13.3`). + +```sh +$ git tag +``` + +### Step 5. Push the release branch changes and tag to github + +The branch and tag should be pushed directly to the main repository +(https://github.com/expressjs/express). + +```sh +$ git push origin +$ git push origin +``` + +### Step 6. Publish to npmjs.com + +Ensure your local working copy is completely clean (no extra or changed files). +You can use `git status` for this purpose. + +```sh +$ npm login +$ npm publish +``` + +**NOTE:** The version number to publish will be picked up automatically from + package.json. diff --git a/charters/Security.md b/charters/Security.md new file mode 100644 index 0000000..cdcd7a6 --- /dev/null +++ b/charters/Security.md @@ -0,0 +1,46 @@ +# Security Policies and Procedures + +This document outlines security procedures and general policies for the Express +project. + + * [Reporting a Bug](#reporting-a-bug) + * [Disclosure Policy](#disclosure-policy) + * [Comments on this Policy](#comments-on-this-policy) + +## Reporting a Bug + +The Express team and community take all security bugs in Express seriously. +Thank you for improving the security of Express. We appreciate your efforts and +responsible disclosure and will make every effort to acknowledge your +contributions. + +Report security bugs by emailing the lead maintainer in the Readme.md file. + +To ensure the timely response to your report, please ensure that the entirety +of the report is contained within the email body and not solely behind a web +link or an attachment. + +The lead maintainer will acknowledge your email within 48 hours, and will send a +more detailed response within 48 hours indicating the next steps in handling +your report. After the initial reply to your report, the security team will +endeavor to keep you informed of the progress towards a fix and full +announcement, and may ask for additional information or guidance. + +Report security bugs in third-party modules to the person or team maintaining +the module. + +## Disclosure Policy + +When the security team receives a security bug report, they will assign it to a +primary handler. This person will coordinate the fix and release process, +involving the following steps: + + * Confirm the problem and determine the affected versions. + * Audit code to find any potential similar problems. + * Prepare fixes for all releases still under maintenance. These fixes will be + released as fast as possible to npm. + +## Comments on this Policy + +If you have suggestions on how this process could be improved please submit a +pull request. diff --git a/charters/Triager-Guide.md b/charters/Triager-Guide.md new file mode 100644 index 0000000..a2909ef --- /dev/null +++ b/charters/Triager-Guide.md @@ -0,0 +1,63 @@ +# Express Triager Guide + +## Issue Triage Process + +When a new issue or pull request is opened the issue will be labeled with `needs triage`. +If a triage team member is available they can help make sure all the required information +is provided. Depending on the issue or PR there are several next labels they can add for further +classification: + +* `needs triage`: This can be kept if the triager is unsure which next steps to take +* `awaiting more info`: If more info has been requested from the author, apply this label. +* `question`: User questions that do not appear to be bugs or enhancements. +* `discuss`: Topics for discussion. Might end in an `enhancement` or `question` label. +* `bug`: Issues that present a reasonable conviction there is a reproducible bug. +* `enhancement`: Issues that are found to be a reasonable candidate feature additions. + +In all cases, issues may be closed by maintainers if they don't receive a timely response when +further information is sought, or when additional questions are asked. + +## Approaches and Best Practices for getting into triage contributions + +Review the organization's [StatusBoard](https://expressjs.github.io/statusboard/), +pay special attention to these columns: stars, watchers, open issues, and contributors. +This gives you a general idea about the criticality and health of the repository. +Pick a few projects based on that criteria, your interests, and skills (existing or aspiring). + +Review the project's contribution guideline if present. In a nutshell, +commit to the community's standards and values. Review the +documentation, for most of the projects it is just the README.md, and +make sure you understand the key APIs, semantics, configurations, and use cases. + +It might be helpful to write your own test apps to re-affirm your +understanding of the key functions. This may identify some gaps in +documentation, record those as they might be good PR's to open. +Skim through the issue backlog; identify low hanging issues and mostly new ones. +From those, attempt to recreate issues based on the OP description and +ask questions if required. No question is a bad question! + +## Removal of Triage Role + +There are a few cases where members can be removed as triagers: + +- Breaking the CoC or project contributor guidelines +- Abuse or misuse of the role as deemed by the TC +- Lack of participation for more than 6 months + +If any of these happen we will discuss as a part of the triage portion of the regular TC meetings. +If you have questions feel free to reach out to any of the TC members. + +## Other Helpful Hints: + +- Everyone is welcome to attend the [Express Technical Committee Meetings](https://github.com/expressjs/discussions#expressjs-tc-meetings), and as a triager, it might help to get a better idea of what's happening with the project. +- When exploring the module's functionality there are a few helpful steps: + - Turn on `DEBUG=*` (see https://www.npmjs.com/package/debug) to get detailed log information + - It is also a good idea to do live debugging to follow the control flow, try using `node --inspect` + - It is a good idea to make at least one pass of reading through the entire source +- When reviewing the list of open issues there are some common types and suggested actions: + - New/unattended issues or simple questions: A good place to start + - Hard bugs & ongoing discussions: always feel free to chime in and help + - Issues that imply gaps in the documentation: open PRs with changes or help the user to do so +- For recurring issues, it is helpful to create functional examples to demonstrate (publish as gists or a repo) +- Review and identify the maintainers. If necessary, at-mention one or more of them if you are unsure what to do +- Make sure all your interactions are professional, welcoming, and respectful to the parties involved.