Initial RFC process (based on reactjs/rfcs)

.vscode/extensions.json

@@ -0,0 +1,20 @@
+{
+  // See http://go.microsoft.com/fwlink/?LinkId=827846
+  // for the documentation about the extensions.json format
+  "recommendations": [
+    // Foam's own extension
+    "foam.foam-vscode",
+
+    // Tons of markdown goodies (lists, tables of content, so much more)
+    "yzhang.markdown-all-in-one",
+
+    // [[wiki-links]], backlinking etc
+    "kortina.vscode-markdown-notes",
+
+    // Graph visualizer
+    "tchayen.markdown-links",
+
+    // Understated grayscale theme (light and dark variants)
+    "philipbe.theme-gray-matter"
+  ]
+}

.vscode/foam.json

@@ -0,0 +1,4 @@
+{
+  "purpose": "this file exists to tell the foam-vscode plugin that it's currently in a foam workspace",
+  "future": "we may use this for custom configuration"
+}

.vscode/settings.json

@@ -0,0 +1,17 @@
+{
+  "files.autoSave": "onFocusChange",
+  "editor.minimap.enabled": false,
+  "editor.wrappingIndent": "indent",
+  "editor.overviewRulerBorder": false,
+  "editor.lineHeight": 24,
+  "workbench.colorTheme": "Gray Matter Light",
+  "[markdown]": {
+    "editor.quickSuggestions": {
+      "other": true,
+      "comments": false,
+      "strings": false
+    }
+  },
+  "git.enableSmartCommit": true,
+  "git.postCommitCommand": "sync"
+}

0000-template.md

@@ -0,0 +1,60 @@
+- Start Date: (fill me in with today's date, YYYY-MM-DD)
+- RFC PR: (leave this empty)
+- Foam Issue: (leave this empty)
+
+# Summary
+
+Brief explanation of the feature, change or process.
+
+# Basic example
+
+If the proposal involves a new or changed API, include a basic code example.
+
+If the proposal involves a new or changed user interface element, include a description, prototype, or mock-up of the change.
+
+Omit this section if it's not applicable.
+
+# Motivation
+
+Why are we doing this? What use cases does it support? What is the expected
+outcome?
+
+Please focus on explaining the motivation so that if this RFC is not accepted,
+the motivation could be used to develop alternative solutions. In other words,
+enumerate the constraints you are trying to solve without coupling them too
+closely to the solution you have in mind.
+
+# Detailed design
+
+This is the bulk of the RFC. Explain the design in enough detail for somebody
+familiar with Foam to understand, and for somebody familiar with the
+implementation to implement. This should get into specifics and corner-cases,
+and include examples of how the feature is used. Any new terminology should be
+defined here.
+
+# Drawbacks
+
+Why should we *not* do this? Please consider:
+
+- implementation cost, both in term of code size, effort and complexity
+- whether the proposed feature can be implemented in user space, a recipe, or a third party extension
+- whether the proposed feature makes it more difficult for non-programmers to use Foam.
+- integration of this feature with other existing and planned features
+- cost of migrating existing Foam workspaces (is it a breaking change?)
+
+There are tradeoffs to choosing any path. Attempt to identify them here.
+
+# Alternatives
+
+What other designs have been considered? What is the impact of not doing this?
+
+# Adoption strategy
+
+If we implement this proposal, how will existing Foam users adopt it? Is
+this a breaking change? Should we coordinate with
+other projects or extensions?
+
+# Unresolved questions
+
+Optional, but suggested for first drafts. What parts of the design are still
+TBD?

CODE_OF_CONDUCT.md

@@ -0,0 +1,3 @@
+# Code of Conduct
+
+This repository falls under the standard [Foam Code of Conduct](https://foambubble.github.io/foam/code-of-conduct), and we expect all participants and discussions to adhere to.

LICENSE.md

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2020-present, Jani Eväkallio
+
+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:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+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

@@ -0,0 +1,124 @@
+# Foam RFCs
+
+Many changes, including bug fixes and documentation improvements can be
+implemented and reviewed via the normal GitHub pull request workflow.
+
+Some changes though are "substantial", and we ask that these be put
+through a bit of a design process and produce a consensus among the Foam
+maintainers and the sub-teams.
+
+The "RFC" (request for comments) process is intended to provide a
+consistent and controlled path for new features to enter the project.
+
+[Active RFC List](https://github.com/foambubble/rfcs/pulls)
+
+Foam is still **actively developing** this process, and it will still change as
+more features are implemented and the community settles on specific approaches
+to feature development.
+
+## When to follow this process
+
+You should consider using this process if you intend to make "substantial"
+changes to Foam or its documentation. Some examples that would benefit
+from an RFC are:
+
+   - A new feature that creates new API surface area or UI functionality
+   - The removal of features that already shipped.
+   - The introduction of new idiomatic usage or conventions, even if they
+     do not include code changes to Foam itself.
+
+The RFC process is a great opportunity to get more eyeballs on your proposal
+before it becomes a part of a released version of Foam. Quite often, even
+proposals that seem "obvious" can be significantly improved once a wider
+group of interested people have a chance to weigh in.
+
+The RFC process can also be helpful to encourage discussions about a proposed
+feature as it is being designed, and incorporate important constraints into
+the design while it's easier to change, before the design has been fully
+implemented.
+
+Some changes do not require an RFC:
+
+  - Rephrasing, reorganizing or refactoring
+  - New documentation sections
+  - Bugfixes, minor improvements to existing functionality
+  - Additions only likely to be _noticed by_ other maintainers-of-Foam,
+  invisible to users-of-Foam.
+
+## What the process is
+
+In short, to get a major feature added to Foam, one usually first gets
+the RFC merged into the RFC repo as a markdown file. At that point the RFC
+is 'active' and may be implemented with the goal of eventual inclusion
+into Foam.
+
+* Fork the RFC repo http://github.com/foambubble/rfcs
+* Copy `0000-template.md` to `text/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 not
+present convincing motivation, demonstrate understanding of the
+impact of the design, or are disingenuous about the drawbacks or
+alternatives tend to be poorly-received**.
+* Submit a pull request. As a pull request the RFC will receive design
+feedback from the larger community, and the author should be prepared
+to revise it in response.
+* Build consensus and integrate feedback. RFCs that have broad support
+are much more likely to make progress than those that don't receive any
+comments.
+* Eventually, the team will decide whether the RFC is a candidate
+for inclusion in Foam.
+* An RFC can be modified based upon feedback from the team and community.
+Significant modifications may trigger a new final comment period.
+* An RFC may be rejected by the team after public discussion has settled
+and comments have been made summarizing the rationale for rejection. A member of
+the team should then close the RFCs associated pull request.
+* An RFC may be accepted at the close of its final comment period. A team
+member will merge the RFCs associated pull request, at which point the RFC will
+become 'active'.
+
+## The RFC life-cycle
+
+Once an RFC becomes active, then authors may implement it and submit the
+feature as a pull request to the Foam repo. Becoming 'active' is not a rubber
+stamp, and in particular still does not mean the feature will ultimately
+be merged; it does mean that the core team has agreed to it in principle
+and 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 its
+implementation, nor whether anybody is currently working on it. The team or 
+sub-team taking responsibility of the feature will choose how to prioritize it. 
+
+Modifications to active RFCs can be done in followup PRs. We strive
+to write each RFC in a manner that it will reflect the final design of
+the feature; but the nature of the process means that we cannot expect
+every merged RFC to actually reflect what the end result will be at
+the time of the next major release; therefore we try to keep each RFC
+document somewhat in sync with the language feature as planned,
+tracking such changes via followup pull requests to the document.
+
+## Implementing an RFC
+
+The author of an RFC is not obligated to implement it. Of course, the
+RFC author (like any other developer) is welcome to post an
+implementation for review after the RFC has been accepted.
+
+The likelihood of a feature getting shipped is significantly improved if you are
+able to participate in implementing yourself, or if you are able to rally other
+contributors to your cause and motivate them to work on the feature. 
+A feature may be worked on by the same person(s) who created the RFC, but
+this is not a requirement. It is perfectly valid to open a RFC without intending
+(or being able) to implement it yourself.
+
+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).
+
+**This RFC process is subject to change. If it's not working for us, we'll improve it, or replace it with a more suitable process.**
+
+**Foams's RFC process owes its inspiration to the [React RFC process], which in turn is takes inspiration from [Yarn RFC process], [Rust RFC process], and [Ember RFC process]**
+
+[Yarn RFC process]: https://github.com/reactjs/rfcs
+[Yarn RFC process]: https://github.com/yarnpkg/rfcs
+[Rust RFC process]: https://github.com/rust-lang/rfcs
+[Ember RFC process]: https://github.com/emberjs/rfcs