Repository files navigation

Many changes, including bug fixes and documentation improvements can beimplemented and reviewed via the normal GitHub pull request workflow.

Some changes though are "substantial", and we ask that these be putthrough a bit of a design process and produce a consensus among the Momentcore team.

The "RFC" (request for comments) process is intended to provide aconsistent and controlled path for new features to enter the library.

Active RFC List

You need to follow this process if you intend to make "substantial"changes to Moment, Moment Timezone or its documentation. What constitutes a"substantial" change is evolving based on community norms, but mayinclude the following.

• A new feature that creates new API surface area.
• The removal of features that already shipped.
• The introduction of new idiomatic usage or conventions, even if theydo not include code changes to Moment itself.

Some changes do not require an RFC:

• Rephrasing, reorganizing or refactoring
• Addition or removal of warnings
• Additions that strictly improve objective, numerical qualitycriteria (speedup, better browser support)
• Additions only likely to benoticed by other implementors-of-Moment,invisible to users-of-Moment.

If you submit a pull request to implement a new feature without goingthrough the RFC process, it may be closed with a polite request tosubmit an RFC first.

It's often helpful to get feedback on your concept before diving into thelevel of API design detail required for an RFC.You may open anissue on this repo to start a high-level discussion, with the goal ofeventually formulating an RFC pull request with the specific implementationdesign.

In short, to get a major feature added to Moment, one must first get theRFC merged into the RFC repo as a markdown file. At that point the RFCis 'active' and may be implemented with the goal of eventual inclusioninto Moment.

• Fork the RFC repohttps://github.com/moment/moment-rfcs
• Copy0000-template.md totext/0000-my-feature.md (where'my-feature' is descriptive. don't assign an RFC number yet).
• Fill in the RFC. Put care into the details:RFCs that do notpresent convincing motivation, demonstrate understanding of theimpact of the design, or are disingenuous about the drawbacks oralternatives tend to be poorly-received.
• Submit a pull request. As a pull request the RFC will receive designfeedback from the larger community, and the author should be preparedto revise it in response.
• Build consensus and integrate feedback. RFCs that have broad supportare much more likely to make progress than those that don't receive anycomments.
• Eventually, somebody on the core team will either accept the RFC bymerging the pull request and assigning the RFC a number, at which pointthe RFC is 'active', or reject it by closing the pull request.

Once an RFC becomes active then authors may implement it and submit thefeature as a pull request to the Moment repo. Becoming 'active' is not a rubberstamp, and in particular still does not mean the feature will ultimatelybe merged; it does mean that the core team has agreed to it in principleand are amenable to merging it.

Furthermore, the fact that a given RFC has been accepted and is'active' implies nothing about what priority is assigned to itsimplementation, nor whether anybody is currently working on it.

Modifications to active RFC's can be done in followup PR's. We striveto write each RFC in a manner that it will reflect the final design ofthe feature; but the nature of the process means that we cannot expectevery merged RFC to actually reflect what the end result will be atthe time of the next major release; therefore we try to keep each RFCdocument somewhat in sync with the language feature as planned,tracking such changes via followup pull requests to the document.

The author of an RFC is not obligated to implement it. Of course, theRFC author (like any other developer) is welcome to post animplementation for review after the RFC has been accepted.

If you are interested in working on the implementation for an 'active'RFC, but cannot determine if someone else is already working on it,feel free to ask (e.g. by leaving a comment on the associated issue).

Each month the core team will attempt to review some set of open RFCpull requests.

We try to make sure that any RFC that we accept is accepted at themonthly team meeting. Every accepted feature should have a core teamchampion, who will represent the feature and its progress.

Moment's RFC process owes its inspiration to theEmber RFC process andRust RFC process