Skip to content

Commit 1773b7e

Browse files
matthewhudsonmatthewhudson
committed
Initial.
0 parents  commit 1773b7e

File tree

5 files changed

+273
-0
lines changed

5 files changed

+273
-0
lines changed

‎.gitignore

+86
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,86 @@
1+
2+
# Created by https://www.gitignore.io/api/linux,windows,macos,visualstudiocode
3+
# Edit at https://www.gitignore.io/?templates=linux,windows,macos,visualstudiocode
4+
5+
### Linux ###
6+
*~
7+
8+
# temporary files which can be created if a process still has a handle open of a deleted file
9+
.fuse_hidden*
10+
11+
# KDE directory preferences
12+
.directory
13+
14+
# Linux trash folder which might appear on any partition or disk
15+
.Trash-*
16+
17+
# .nfs files are created when an open file is removed but is still being accessed
18+
.nfs*
19+
20+
### macOS ###
21+
# General
22+
.DS_Store
23+
.AppleDouble
24+
.LSOverride
25+
26+
# Icon must end with two \r
27+
Icon
28+
29+
# Thumbnails
30+
._*
31+
32+
# Files that might appear in the root of a volume
33+
.DocumentRevisions-V100
34+
.fseventsd
35+
.Spotlight-V100
36+
.TemporaryItems
37+
.Trashes
38+
.VolumeIcon.icns
39+
.com.apple.timemachine.donotpresent
40+
41+
# Directories potentially created on remote AFP share
42+
.AppleDB
43+
.AppleDesktop
44+
Network Trash Folder
45+
Temporary Items
46+
.apdisk
47+
48+
### VisualStudioCode ###
49+
.vscode
50+
.vscode/*
51+
!.vscode/settings.json
52+
!.vscode/tasks.json
53+
!.vscode/launch.json
54+
!.vscode/extensions.json
55+
56+
### VisualStudioCode Patch ###
57+
# Ignore all local history of files
58+
.history
59+
60+
### Windows ###
61+
# Windows thumbnail cache files
62+
Thumbs.db
63+
Thumbs.db:encryptable
64+
ehthumbs.db
65+
ehthumbs_vista.db
66+
67+
# Dump file
68+
*.stackdump
69+
70+
# Folder config file
71+
[Dd]esktop.ini
72+
73+
# Recycle Bin used on file shares
74+
$RECYCLE.BIN/
75+
76+
# Windows Installer files
77+
*.cab
78+
*.msi
79+
*.msix
80+
*.msm
81+
*.msp
82+
83+
# Windows shortcuts
84+
*.lnk
85+
86+
# End of https://www.gitignore.io/api/linux,windows,macos,visualstudiocode

‎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+
- Webpipe 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 Webpipes 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 Webpipes
39+
- integration of this feature with other existing and planned features
40+
- cost of migrating existing Webpipe 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 Webpipe 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 Webpipe patterns?
58+
59+
Would the acceptance of this proposal mean the Webpipe documentation must be
60+
re-organized or altered? Does it change how Webpipes is taught to new developers
61+
at any level?
62+
63+
How should this feature be taught to existing Webpipe developers?
64+
65+
# Unresolved questions
66+
67+
Optional, but suggested for first drafts. What parts of the design are still
68+
TBD?

‎README.md

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

‎text/.gitkeep

Whitespace-only changes.

‎text/000-cli-redesign.md

Whitespace-only changes.

0 commit comments

Comments
 (0)