Skip to content

Commit c22b065

Browse files
author
Kevin Venkiteswaran
committed
Initial commit
0 parents  commit c22b065

27 files changed

+2983
-0
lines changed

‎0000-template.md

+68
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,68 @@
1+
- Start Date: (fill me in with today's date, YYYY-MM-DD)
2+
- RFC PR: (leave this empty)
3+
- Lightning Web Component Issue: (leave this empty)
4+
5+
# Summary
6+
7+
Brief explanation of the feature.
8+
9+
# Basic example
10+
11+
If the proposal involves a new or changed API, include a basic code example.
12+
Omit this section if it's not applicable.
13+
14+
# Motivation
15+
16+
Why are we doing this? What use cases does it support? What is the expected
17+
outcome?
18+
19+
Please focus on explaining the motivation so that if this RFC is not accepted,
20+
the motivation could be used to develop alternative solutions. In other words,
21+
enumerate the constraints you are trying to solve without coupling them too
22+
closely to the solution you have in mind.
23+
24+
# Detailed design
25+
26+
This is the bulk of the RFC. Explain the design in enough detail for somebody
27+
familiar with Lightning Web Components to understand, and for somebody familiar with the
28+
implementation to implement. This should get into specifics and corner-cases,
29+
and include examples of how the feature is used. Any new terminology should be
30+
defined here.
31+
32+
# Drawbacks
33+
34+
Why should we *not* do this? Please consider:
35+
36+
- implementation cost, both in term of code size and complexity
37+
- whether the proposed feature can be implemented in user space
38+
- the impact on teaching people Lightning Web Components
39+
- integration of this feature with other existing and planned features
40+
- cost of migrating existing Lightning Web Components applications (is it a breaking change?)
41+
42+
There are tradeoffs to choosing any path. Attempt to identify them here.
43+
44+
# Alternatives
45+
46+
What other designs have been considered? What is the impact of not doing this?
47+
48+
# Adoption strategy
49+
50+
If we implement this proposal, how will existing Lightning Web Components developers adopt it? Is
51+
this a breaking change? Can we write a codemod? Should we coordinate with
52+
other projects or libraries?
53+
54+
# How we teach this
55+
56+
What names and terminology work best for these concepts and why? How is this
57+
idea best presented? As a continuation of existing Lightning Web Components patterns?
58+
59+
Would the acceptance of this proposal mean the Lightning Web Components documentation must be
60+
re-organized or altered? Does it change how Lightning Web Components is taught to new developers
61+
at any level?
62+
63+
How should this feature be taught to existing Lightning Web Components developers?
64+
65+
# Unresolved questions
66+
67+
Optional, but suggested for first drafts. What parts of the design are still
68+
TBD?

‎CODE_OF_CONDUCT.md

+105
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,105 @@
1+
# Salesforce Open Source Community Code of Conduct
2+
3+
## About the Code of Conduct
4+
5+
Equality is a core value at Salesforce. We believe a diverse and inclusive
6+
community fosters innovation and creativity, and are committed to building a
7+
culture where everyone feels included.
8+
9+
Salesforce open-source projects are committed to providing a friendly, safe, and
10+
welcoming environment for all, regardless of gender identity and expression,
11+
sexual orientation, disability, physical appearance, body size, ethnicity, nationality,
12+
race, age, religion, level of experience, education, socioeconomic status, or
13+
other similar personal characteristics.
14+
15+
The goal of this code of conduct is to specify a baseline standard of behavior so
16+
that people with different social values and communication styles can work
17+
together effectively, productively, and respectfully in our open source community.
18+
It also establishes a mechanism for reporting issues and resolving conflicts.
19+
20+
All questions and reports of abusive, harassing, or otherwise unacceptable behavior
21+
in a Salesforce open-source project may be reported by contacting the Salesforce
22+
Open Source Conduct Committee at [email protected].
23+
24+
## Our Pledge
25+
26+
In the interest of fostering an open and welcoming environment, we as
27+
contributors and maintainers pledge to making participation in our project and
28+
our community a harassment-free experience for everyone, regardless of gender
29+
identity and expression, sexual orientation, disability, physical appearance,
30+
body size, ethnicity, nationality, race, age, religion, level of experience, education,
31+
socioeconomic status, or other similar personal characteristics.
32+
33+
## Our Standards
34+
35+
Examples of behavior that contributes to creating a positive environment
36+
include:
37+
38+
* Using welcoming and inclusive language
39+
* Being respectful of differing viewpoints and experiences
40+
* Gracefully accepting constructive criticism
41+
* Focusing on what is best for the community
42+
* Showing empathy toward other community members
43+
44+
Examples of unacceptable behavior by participants include:
45+
46+
* The use of sexualized language or imagery and unwelcome sexual attention or
47+
advances
48+
* Personal attacks, insulting/derogatory comments, or trolling
49+
* Public or private harassment
50+
* Publishing, or threatening to publish, others' private information—such as
51+
a physical or electronic address—without explicit permission
52+
* Other conduct which could reasonably be considered inappropriate in a
53+
professional setting
54+
* Advocating for or encouraging any of the above behaviors
55+
56+
## Our Responsibilities
57+
58+
Project maintainers are responsible for clarifying the standards of acceptable
59+
behavior and are expected to take appropriate and fair corrective action in
60+
response to any instances of unacceptable behavior.
61+
62+
Project maintainers have the right and responsibility to remove, edit, or
63+
reject comments, commits, code, wiki edits, issues, and other contributions
64+
that are not aligned with this Code of Conduct, or to ban temporarily or
65+
permanently any contributor for other behaviors that they deem inappropriate,
66+
threatening, offensive, or harmful.
67+
68+
## Scope
69+
70+
This Code of Conduct applies both within project spaces and in public spaces
71+
when an individual is representing the project or its community. Examples of
72+
representing a project or community include using an official project email
73+
address, posting via an official social media account, or acting as an appointed
74+
representative at an online or offline event. Representation of a project may be
75+
further defined and clarified by project maintainers.
76+
77+
## Enforcement
78+
79+
Instances of abusive, harassing, or otherwise unacceptable behavior may be
80+
reported by contacting the Salesforce Open Source Conduct Committee
81+
at [email protected]. All complaints will be reviewed and investigated
82+
and will result in a response that is deemed necessary and appropriate to the
83+
circumstances. The committee is obligated to maintain confidentiality with
84+
regard to the reporter of an incident. Further details of specific enforcement
85+
policies may be posted separately.
86+
87+
Project maintainers who do not follow or enforce the Code of Conduct in good
88+
faith may face temporary or permanent repercussions as determined by other
89+
members of the project's leadership and the Salesforce Open Source Conduct
90+
Committee.
91+
92+
## Attribution
93+
94+
This Code of Conduct is adapted from the [Contributor Covenant][contributor-covenant-home],
95+
version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html.
96+
It includes adaptions and additions from [Go Community Code of Conduct][golang-coc],
97+
[CNCF Code of Conduct][cncf-coc], and [Microsoft Open Source Code of Conduct][microsoft-coc].
98+
99+
This Code of Conduct is licensed under the [Creative Commons Attribution 3.0 License][cc-by-3-us].
100+
101+
[contributor-covenant-home]: https://www.contributor-covenant.org (https://www.contributor-covenant.org/)
102+
[golang-coc]: https://golang.org/conduct
103+
[cncf-coc]: https://github.com/cncf/foundation/blob/master/code-of-conduct.md
104+
[microsoft-coc]: https://opensource.microsoft.com/codeofconduct/
105+
[cc-by-3-us]: https://creativecommons.org/licenses/by/3.0/us/

‎CONTRIBUTING.md

+27
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
# Contributing to lwc-rfcs
2+
3+
We want to make contributing to this project as easy and transparent as possible.
4+
5+
## Pull Requests
6+
We actively welcome your pull requests.
7+
8+
1. Fork the repo and create your branch from `master`.
9+
2. If you've added code that should be tested, add tests.
10+
3. If you've changed APIs, update the documentation.
11+
4. Ensure the test suite passes.
12+
5. Make sure your code lints.
13+
6. If you haven't already, complete the Contributor License Agreement ("CLA").
14+
15+
## Contributor License Agreement ("CLA")
16+
In order to accept your pull request, we need you to submit a CLA. You only need
17+
to do this once to work on any of Salesforce's open source projects.
18+
19+
Complete your CLA here: <https://cla.salesforce.com/sign-cla>
20+
21+
## Issues
22+
We use GitHub issues to track public bugs. Please ensure your description is
23+
clear and has sufficient instructions to be able to reproduce the issue.
24+
25+
## License
26+
By contributing to rfcs, you agree that your contributions will be licensed
27+
under the LICENSE file in the root directory of this source tree.

‎LICENSE

+10
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
MIT LICENSE
2+
3+
Copyright (c) 2018, Salesforce.com, Inc.
4+
All rights reserved.
5+
6+
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
7+
8+
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
9+
10+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

‎README.md

+139
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,139 @@
1+
# Lightning Web Component RFCs
2+
3+
Many changes, including bug fixes and documentation improvements can be
4+
implemented and reviewed via the normal GitHub pull request workflow.
5+
6+
Some changes though are "substantial", and we ask that these be put
7+
through a bit of a design process and produce a consensus among the Lightning Web Components
8+
core team.
9+
10+
The "RFC" (request for comments) process is intended to provide a
11+
consistent and controlled path for new features to enter the project.
12+
13+
[Active RFC List](https://github.com/salesforce/lwc-rfcs/pulls)
14+
15+
Lightning Web Components is still **actively developing** this process, and it will still change as
16+
more features are implemented and the community settles on specific approaches
17+
to feature development.
18+
19+
## Contributor License Agreement (CLA)
20+
21+
In order to accept your pull request, we need you to submit a CLA. You only need
22+
to do this once, so if you've done this for another Salesforce open source
23+
project, you're good to go. If you are submitting a pull request for the first
24+
time, just let us know that you have completed the CLA and we can cross-check
25+
with your GitHub username.
26+
27+
**[Complete your CLA here.](https://cla.salesforce.com/sign-cla)**
28+
29+
## When to follow this process
30+
31+
You should consider using this process if you intend to make "substantial"
32+
changes to Lightning Web Components or its documentation. Some examples that would benefit
33+
from an RFC are:
34+
35+
- A new feature that creates new API surface area, and would
36+
require a feature flag if introduced.
37+
- The removal of features that already shipped as part of the release
38+
channel.
39+
- The introduction of new idiomatic usage or conventions, even if they
40+
do not include code changes to Lightning Web Components itself.
41+
42+
The RFC process is a great opportunity to get more eyeballs on your proposal
43+
before it becomes a part of a released version of Lightning Web Components. Quite often, even
44+
proposals that seem "obvious" can be significantly improved once a wider
45+
group of interested people have a chance to weigh in.
46+
47+
The RFC process can also be helpful to encourage discussions about a proposed
48+
feature as it is being designed, and incorporate important constraints into
49+
the design while it's easier to change, before the design has been fully
50+
implemented.
51+
52+
Some changes do not require an RFC:
53+
54+
- Rephrasing, reorganizing or refactoring
55+
- Addition or removal of warnings
56+
- Additions that strictly improve objective, numerical quality
57+
criteria (speedup, better browser support)
58+
- Additions only likely to be _noticed by_ other implementors-of-Lightning Web Components,
59+
invisible to users-of-Lightning Web Components.
60+
61+
## What the process is
62+
63+
In short, to get a major feature added to Lightning Web Components, one usually first gets
64+
the RFC merged into the RFC repo as a markdown file. At that point the RFC
65+
is 'active' and may be implemented with the goal of eventual inclusion
66+
into Lightning Web Components.
67+
68+
* Fork the RFC repo http://github.com/salesforce/lwc-rfcs
69+
* Copy `0000-template.md` to `text/0000-my-feature.md` (where
70+
'my-feature' is descriptive. Don't assign an RFC number yet).
71+
* Fill in the RFC. Put care into the details: **RFCs that do not
72+
present convincing motivation, demonstrate understanding of the
73+
impact of the design, or are disingenuous about the drawbacks or
74+
alternatives tend to be poorly-received**.
75+
* Submit a pull request. As a pull request the RFC will receive design
76+
feedback from the larger community, and the author should be prepared
77+
to revise it in response.
78+
* Build consensus and integrate feedback. RFCs that have broad support
79+
are much more likely to make progress than those that don't receive any
80+
comments.
81+
* Eventually, the team will decide whether the RFC is a candidate
82+
for inclusion in Lightning Web Components.
83+
* RFCs that are candidates for inclusion in Lightning Web Components will enter a "final comment
84+
period" lasting 3 calendar days. The beginning of this period will be signaled with a
85+
comment and tag on the RFCs pull request.
86+
* An RFC can be modified based upon feedback from the team and community.
87+
Significant modifications may trigger a new final comment period.
88+
* An RFC may be rejected by the team after public discussion has settled
89+
and comments have been made summarizing the rationale for rejection. A member of
90+
the team should then close the RFCs associated pull request.
91+
* An RFC may be accepted at the close of its final comment period. A team
92+
member will merge the RFCs associated pull request, at which point the RFC will
93+
become 'active'.
94+
95+
## The RFC life-cycle
96+
97+
Once an RFC becomes active, then authors may implement it and submit the
98+
feature as a pull request to the Lightning Web Components repo. Becoming 'active' is not a rubber
99+
stamp, and in particular still does not mean the feature will ultimately
100+
be merged; it does mean that the core team has agreed to it in principle
101+
and are amenable to merging it.
102+
103+
Furthermore, the fact that a given RFC has been accepted and is
104+
'active' implies nothing about what priority is assigned to its
105+
implementation, nor whether anybody is currently working on it.
106+
107+
Modifications to active RFCs can be done in followup PRs. We strive
108+
to write each RFC in a manner that it will reflect the final design of
109+
the feature; but the nature of the process means that we cannot expect
110+
every merged RFC to actually reflect what the end result will be at
111+
the time of the next major release; therefore we try to keep each RFC
112+
document somewhat in sync with the language feature as planned,
113+
tracking such changes via followup pull requests to the document.
114+
115+
## Implementing an RFC
116+
117+
The author of an RFC is not obligated to implement it. Of course, the
118+
RFC author (like any other developer) is welcome to post an
119+
implementation for review after the RFC has been accepted.
120+
121+
If you are interested in working on the implementation for an 'active'
122+
RFC, but cannot determine if someone else is already working on it,
123+
feel free to ask (e.g. by leaving a comment on the associated issue).
124+
125+
## Reviewing RFCs
126+
127+
Each week the team will attempt to review some set of open RFC
128+
pull requests.
129+
130+
We try to make sure that any RFC that we accept is accepted at the
131+
weekly team meeting. Every accepted feature should have a core team champion,
132+
who will represent the feature and its progress.
133+
134+
**Lightning Web Components's RFC process owes its inspiration to the [React RFC process], [Yarn RFC process], [Rust RFC process], and [Ember RFC process]**
135+
136+
[React RFC process]: https://github.com/reactjs/rfcs
137+
[Yarn RFC process]: https://github.com/yarnpkg/rfcs
138+
[Rust RFC process]: https://github.com/rust-lang/rfcs
139+
[Ember RFC process]: https://github.com/emberjs/rfcs

0 commit comments

Comments
 (0)