From db4778668463cc095cddffc60d3962e2f8d39f8d Mon Sep 17 00:00:00 2001 From: Jean Burellier Date: Thu, 29 Feb 2024 22:40:04 +0100 Subject: [PATCH] chore: move documentation and charters to the Admin repository --- Charter.md | 92 --------------------- Code-Of-Conduct.md | 139 ------------------------------- Collaborator-Guide.md | 51 ------------ Contributing.md | 160 ------------------------------------ Readme-Guide.md | 125 ---------------------------- Readme.md | 8 +- Release-Process.md | 186 ------------------------------------------ Security.md | 46 ----------- Triager-Guide.md | 63 -------------- 9 files changed, 6 insertions(+), 864 deletions(-) delete mode 100644 Charter.md delete mode 100644 Code-Of-Conduct.md delete mode 100644 Collaborator-Guide.md delete mode 100644 Contributing.md delete mode 100644 Readme-Guide.md delete mode 100644 Release-Process.md delete mode 100644 Security.md delete mode 100644 Triager-Guide.md diff --git a/Charter.md b/Charter.md deleted file mode 100644 index a906e52909..0000000000 --- a/Charter.md +++ /dev/null @@ -1,92 +0,0 @@ -# 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/Code-Of-Conduct.md b/Code-Of-Conduct.md deleted file mode 100644 index bbb8996a65..0000000000 --- a/Code-Of-Conduct.md +++ /dev/null @@ -1,139 +0,0 @@ -# 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/Collaborator-Guide.md b/Collaborator-Guide.md deleted file mode 100644 index 3c73307d61..0000000000 --- a/Collaborator-Guide.md +++ /dev/null @@ -1,51 +0,0 @@ -# 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/Contributing.md b/Contributing.md deleted file mode 100644 index dfe5f13833..0000000000 --- a/Contributing.md +++ /dev/null @@ -1,160 +0,0 @@ -# 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/Readme-Guide.md b/Readme-Guide.md deleted file mode 100644 index 34d4648b9c..0000000000 --- a/Readme-Guide.md +++ /dev/null @@ -1,125 +0,0 @@ -# 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/Readme.md b/Readme.md index d0f3cf56e6..ed2712bf39 100644 --- a/Readme.md +++ b/Readme.md @@ -115,6 +115,10 @@ $ npm install $ node examples/content-negotiation ``` +## Charters + +Charters and all documents linked to how the Express.js project is handled are definied and can be found in the [Admin](https://github.com/expressjs/Admin) repository. + ## Contributing [![Linux Build][github-actions-ci-image]][github-actions-ci-url] @@ -125,11 +129,11 @@ The Express.js project welcomes all constructive contributions. Contributions ta from code for bug fixes and enhancements, to additions and fixes to documentation, additional tests, triaging incoming pull requests and issues, and more! -See the [Contributing Guide](Contributing.md) for more technical details on contributing. +See the [Contributing Guide](https://github.com/expressjs/Admin/charters/Contributing.md) for more technical details on contributing and the [Collaborator Guide](https://github.com/expressjs/Admin/charters/Collaborator-Guide.md). ### Security Issues -If you discover a security vulnerability in Express, please see [Security Policies and Procedures](Security.md). +If you discover a security vulnerability in Express, please see [Security Policies and Procedures](https://github.com/expressjs/Admin/charters/Security.md). ### Running Tests diff --git a/Release-Process.md b/Release-Process.md deleted file mode 100644 index ae740972f7..0000000000 --- a/Release-Process.md +++ /dev/null @@ -1,186 +0,0 @@ -# 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/Security.md b/Security.md deleted file mode 100644 index cdcd7a6e0a..0000000000 --- a/Security.md +++ /dev/null @@ -1,46 +0,0 @@ -# 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/Triager-Guide.md b/Triager-Guide.md deleted file mode 100644 index a2909ef30d..0000000000 --- a/Triager-Guide.md +++ /dev/null @@ -1,63 +0,0 @@ -# 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.