Express and the other projects in the expressjs organization on GitHub are projects of the OpenJs Foundation. These projects are governed under the general policies and guidelines of the Node.js Foundation along with the additional guidelines below.
The Express technical committee consists of active project members, and guides development and maintenance of the Express project. For more information, see Express Community - Technical committee.
The goal of this document is to create a contribution process that:
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.
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.
Anyone can become a triager! Read more about the process of being a triager in the triage process document.
Currently, any existing organization member can nominate a new triager. If you are interested in becoming a triager, our best advice is to actively participate in the community by helping triaging issues and pull requests. As well we recommend to engage in other community activities like attending the TC meetings, and participating in the Slack discussions.
You can also reach out to any of the organization members if you have questions or need guidance.
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.
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 12 months and miss no more than six consecutive TC meetings. Our goal is to increase participation, not punish people for any lack of participation, this guideline should be only be used as such (replace an inactive member with a new active one, for example). 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.
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 an existing captain on the same repo can nominate another committer to the captain role. To do so, they should submit a PR to this document, updating the Active Project Captains section (while maintaining the sort order) with the project name, the nominee’s GitHub handle, and their 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.
expressjs/badgeboard: @wesleytoddexpressjs/basic-auth-connect: @ulisesGasconexpressjs/body-parser: @wesleytodd, @jonchurch, @ulisesGasconexpressjs/compression: @ulisesGasconexpressjs/connect-multiparty: @ulisesGasconexpressjs/cookie-parser: @wesleytodd, @UlisesGasconexpressjs/cookie-session: @ulisesGasconexpressjs/cors: @jonchurch, @ulisesGasconexpressjs/discussions: @wesleytoddexpressjs/errorhandler: @ulisesGasconexpressjs/express-paginate: @ulisesGasconexpressjs/express: @wesleytodd, @ulisesGasconexpressjs/expressjs.com: @crandmck, @jonchurch, @bjohansebasexpressjs/flash: @ulisesGasconexpressjs/generator: @wesleytoddexpressjs/method-override: @ulisesGasconexpressjs/morgan: @jonchurch, @ulisesGasconexpressjs/multer: @LinusU, @ulisesGasconexpressjs/response-time: @UlisesGasconexpressjs/serve-favicon: @ulisesGasconexpressjs/serve-index: @ulisesGasconexpressjs/serve-static: @ulisesGasconexpressjs/session: @ulisesGasconexpressjs/statusboard: @wesleytoddexpressjs/timeout: @ulisesGasconexpressjs/vhost: @ulisesGasconjshttp/accepts: @blakeembreyjshttp/basic-auth: @blakeembreyjshttp/compressible: @blakeembreyjshttp/content-disposition: @blakeembreyjshttp/content-type: @blakeembreyjshttp/cookie: @blakeembreyjshttp/etag: @blakeembreyjshttp/forwarded: @blakeembreyjshttp/fresh: @blakeembreyjshttp/http-assert: @wesleytodd, @jonchurch, @ulisesGasconjshttp/http-errors: @wesleytodd, @jonchurch, @ulisesGasconjshttp/media-typer: @blakeembreyjshttp/methods: @blakeembreyjshttp/mime-db: @blakeembrey, @UlisesGasconjshttp/mime-types: @blakeembrey, @UlisesGasconjshttp/negotiator: @blakeembreyjshttp/on-finished: @wesleytodd, @ulisesGasconjshttp/on-headers: @blakeembreyjshttp/proxy-addr: @wesleytodd, @ulisesGasconjshttp/range-parser: @blakeembreyjshttp/statuses: @blakeembreyjshttp/type-is: @blakeembreyjshttp/vary: @blakeembreypillarjs/cookies: @blakeembreypillarjs/csrf: @ulisesGasconpillarjs/encodeurl: @blakeembreypillarjs/finalhandler: @wesleytodd, @ulisesGasconpillarjs/hbs: @ulisesGasconpillarjs/multiparty: @blakeembreypillarjs/parseurl: @blakeembreypillarjs/path-to-regexp: @blakeembreypillarjs/request: @wesleytoddpillarjs/resolve-path: @blakeembreypillarjs/router: @wesleytodd, @ulisesGasconpillarjs/send: @blakeembreypillarjs/understanding-csrf: @ulisesGasconBy making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
Open issues for the expressjs.com website in https://github.com/expressjs/expressjs.com.
npm run lint.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.
npm install,
then run npm test.npm run lint – fix any issue you
see listed.#123.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:
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.
This document outlines security procedures and general policies for the Express project.
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 [email protected].
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.
Alpha and Beta releases are unstable and not suitable for production use. Vulnerabilities found in pre-releases should be reported according to the Reporting a Bug section. Due to the unstable nature of the branch it is not guaranteed that any fixes will be released in the next pre-release.
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:
We are currently working on a new version of the security model, the most updated version can be found here
If you have suggestions on how this process could be improved please submit a pull request.
This is the contribution documentation for the Expressjs.com website.
Website issues: If you see anything on the site that could use a tune-up, think about how to fix it.
IMPORTANT: All translation submissions are currently paused. See this notice for more information.
We often have bugs or enhancements that need work. You can find these under our repo’s Issues tab. Check out the tags to find something that’s a good match for you.
If you’ve found a bug or a typo, or if you have an idea for an enhancement, you can:
The steps below will guide you through the Expressjs.com contribution process.
So you’ve found a problem that you want to fix, or have a site enhancement you want to make.
Clone the repo and get the code:
git clone https://github.com/expressjs/expressjs.com.git
After you’ve got the code you’re ready to start making your changes!
But just in case you need a little extra explanation, this section below outlines the main sections of the code base, where most changes are likely to be made.
Markdown Page Files:
md files.es directory, for example.Includes Partials and Layout Templates
_includes are partials that are imported and reused across multiple pages.
_includes > api > en > 5x, which is included in every language._layouts are the templates used to wrap the site’s individual pages.
content tag.Blog Markdown Files
_posts directory.CSS or Javascript
css and js folders on the project root.The Express JS website is build using Jeykyll and is hosted on Github Pages.
Now you’ll need a way to see your changes, which means you’ll need a running version of the application. You have two options.
IMPORTANT: We are currently working toward a more streamlined translations workflow. As long as this notice is posted, we will not be accepting any translation submissions.
We highly encourage community translations! We no longer have professional translations, and we believe in the power of our community to provide accurate and helpful translations.
The documentation is translated into these languages:
en)es)fr)it)id)ja)ko)pt-br)ru)sk)th)tr)uk)uz)zh-cn)zh-tw)If you find a translation is missing from the list you can create a new one.
To translate Expressjs.com into a new language, follow these steps:
expressjs.com repository.index.md, api.md, starter/, guide/, advanced/, resources/, 4x/, and 3x/, to the language directory.lang variable in the copied markdown files.title variable in the copied markdown files._includes/ directory, in the respective directories, and make necessary edits to the contents._includes/ directory./en to all the links within the site..github/workflows/translation.yml files with the new language.Many site translations are still missing pages. To find which ones we need help with, you can filter for merged PRs that include the tag for your language, such as requires-translation-es for requires Spanish translation.
If you contribute a page or section translation, please reference the original PR. This helps the person merging your translation to remove the tag from the original PR.