Merge pull request #1 from rtfm-rs/add_ops

Added barebones ops

.github/CODEOWNERS

@@ -0,0 +1 @@
+* @rtfm-rs/devs @korken89 @japaric

.github/bors.toml

@@ -0,0 +1,4 @@
+block_labels = ["S-blocked", "S-waiting-on-team", "needs-decision", "do-not-merge"]
+delete_merged_branches = true
+required_approvals = 1
+status = ["continuous-integration/travis-ci/push"]

.travis.yml

@@ -0,0 +1,14 @@
+language: rust
+
+script:
+  - true
+
+branches:
+  only:
+    - master
+    - staging
+    - trying
+
+notifications:
+  email:
+    on_success: never

0000-template.md

@@ -0,0 +1,47 @@
+- Feature Name: (fill me in with a unique ident, my_awesome_feature)
+- Start Date: (fill me in with today's date, YYYY-MM-DD)
+- RFC PR: (leave this empty)
+- Rust Issue: (leave this empty)
+
+# Summary
+[summary]: #summary
+
+One para explanation of the feature.
+
+# Motivation
+[motivation]: #motivation
+
+Why are we doing this? What use cases does it support? What is the expected outcome?
+
+# Detailed design
+[design]: #detailed-design
+
+This is the bulk of the RFC. Explain the design in enough detail for somebody familiar
+with the language to understand, and for somebody familiar with the compiler to implement.
+This should get into specifics and corner-cases, and include examples of how the feature is used.
+
+# How We Teach This
+[how-we-teach-this]: #how-we-teach-this
+
+What names and terminology work best for these concepts and why? 
+How is this idea best presented—as a continuation of existing Rust patterns, or as a wholly new one?
+
+Would the acceptance of this proposal change how Rust is taught to new users at any level? 
+How should this feature be introduced and taught to existing Rust users?
+
+What additions or changes to the Rust Reference, _The Rust Programming Language_, and/or _Rust by Example_ does it entail?
+
+# Drawbacks
+[drawbacks]: #drawbacks
+
+Why should we *not* do this?
+
+# Alternatives
+[alternatives]: #alternatives
+
+What other designs have been considered? What is the impact of not doing this?
+
+# Unresolved questions
+[unresolved]: #unresolved-questions
+
+What parts of the design are still TBD?

CODE_OF_CONDUCT.md

@@ -0,0 +1,33 @@
+# The Rust Code of Conduct
+
+## Conduct
+
+* We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic.
+* On Matrix and IRC, please avoid using overtly sexual nicknames or other nicknames that might detract from a friendly, safe and welcoming environment for all.
+* Please be kind and courteous. There's no need to be mean or rude.
+* Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer.
+* Please keep unstructured critique to a minimum. If you have solid ideas you want to experiment with, make a fork and see how it works.
+* We will exclude you from interaction if you insult, demean or harass anyone. That is not welcome behavior. We interpret the term "harassment" as including the definition in the [Citizen Code of Conduct](http://citizencodeofconduct.org/); if you have any lack of clarity about what might be included in that concept, please read their definition. In particular, we don't tolerate behavior that excludes people in socially marginalized groups.
+* Private harassment is also unacceptable. No matter who you are, if you feel you have been or are being harassed or made uncomfortable by a community member, please contact one of the channel ops immediately. Whether you're a regular contributor or a newcomer, we care about making this community a safe place for you and we've got your back.
+* Likewise any spamming, trolling, flaming, baiting or other attention-stealing behavior is not welcome.
+
+## Moderation
+
+These are the policies for upholding our community's standards of conduct.
+
+1. Remarks that violate the Rust standards of conduct, including hateful, hurtful, oppressive, or exclusionary remarks, are not allowed. (Cursing is allowed, but never targeting another user, and never in a hateful manner.)
+2. Remarks that moderators find inappropriate, whether listed in the code of conduct or not, are also not allowed.
+3. Moderators will first respond to such remarks with a warning.
+4. If the warning is unheeded, the user will be "kicked," i.e., kicked out of the communication channel to cool off.
+5. If the user comes back and continues to make trouble, they will be banned, i.e., indefinitely excluded.
+6. Moderators may choose at their discretion to un-ban the user if it was a first offense and they offer the offended party a genuine apology.
+7. If a moderator bans someone and you think it was unjustified, please take it up with that moderator, or with a different moderator, **in private**. Complaints about bans in-channel are not allowed.
+8. Moderators are held to a higher standard than other community members. If a moderator creates an inappropriate situation, they should expect less leeway than others.
+
+In the Rust community we strive to go the extra step to look out for each other. Don't just aim to be technically unimpeachable, try to be your best self. In particular, avoid flirting with offensive or sensitive issues, particularly if they're off-topic; this all too often leads to unnecessary fights, hurt feelings, and damaged trust; worse, it can drive people away from the community entirely.
+
+And if someone takes issue with something you said or did, resist the urge to be defensive. Just stop doing what it was they complained about and apologize. Even if you feel you were misinterpreted or unfairly accused, chances are good there was something you could've communicated better — remember that it's your responsibility to make your fellow Rustaceans comfortable. Everyone wants to get along and we are all here first and foremost because we want to talk about cool technology. You will find that people will be eager to assume good intent and forgive as long as you earn their trust.
+
+The enforcement policies listed above apply to all official venues; including the official Matrix room (#rtfm-rs:matrix.org); GitHub repositories under rtfm-rs; and all forums under rtfm-rs.
+
+*Adapted from the [Node.js Policy on Trolling](http://blog.izs.me/post/30036893703/policy-on-trolling) as well as the [Contributor Covenant v1.3.0](https://www.contributor-covenant.org/version/1/3/0/).*

ops/README.md

@@ -0,0 +1 @@
+# Operational notes

ops/hibernating.md

@@ -0,0 +1,21 @@
+# Hibernating
+
+A member that will be absent or busy for an extended period of time and not able
+to participate in the WG during that time should put themselves in "hibernation"
+state. During this hibernation period:
+
+- The member will be removed from their GitHub teams'. `cc @rtfm-rs/$team`
+  will *not* cc them.
+
+- The member name will be removed from the list of teams in the rtfm-rs/rfcs
+  README, but they will be listed under the 'Hibernating' section of that
+  README.
+
+- The member will not be counted when computing the number of votes required to
+  reach majority on matters that concern the teams they are a member of. This
+  includes PRs labeled `T-all` that need a decision.
+
+To enter or leave the hibernation state the member will:
+
+- Notify their teams (e.g. `cc @rtfm-rs/$team`) and send a PR to
+  rtfm-rs/rfcs updating the README to reflect their hibernation state.

ops/matrix.md

@@ -0,0 +1,53 @@
+# Matrix Operational Notes
+
+The RTFM developers use the following Matrix room for our regular
+meetings and community discussion:
+
+[#rtfm-rs:matrix.org](https://matrix.to/#/!yafYEipFNsXDdwiHMT:matrix.org)
+
+The document details the organization of the room.
+
+## Administration
+
+See the [Matrix Moderation Guide](https://matrix.org/docs/guides/moderation)
+for information on how Matrix administration and permissions work.
+
+RTFM [core team](https://github.com/orgs/rtfm-rs/teams/devs) members are
+channel administrators (PL100), responsible for both maintaining the channel as
+required and enforcing the WG's Code of Conduct.
+
+* Can send messages
+* Can invite users
+* Can change room settings
+* Kick and ban users in violation of the Code of Conduct
+* Can remove messages in violation of the Code of Conduct
+* Can notify everyone
+* Can modify widgets
+* Can change room avatar
+* Can change main address for the room
+* Can change history visibility
+* Can change room name
+* Can change other users' permissions
+* Can change topic
+
+All WG members may be channel moderators on request, responsible for enforcing
+the WG's Code of Conduct.
+
+* Can send messages
+* Can invite users
+* Kick and ban users in violation of the Code of Conduct
+* Can remove messages in violation of the Code of Conduct
+* Can notify everyone
+* Can change topic
+
+For a WG member to request to become a channel moderator (or a new core team
+member to become an administrator), they should contact a core team member
+[via GitHub](https://github.com/orgs/rtfm-rs/teams/devs) with their
+Matrix username (e.g., `@username:matrix.org`) to be given moderator
+permissions.
+
+All other room members have no special powers:
+
+* Can send messages
+* Can invite users
+

ops/msrv.md

@@ -0,0 +1,44 @@
+# Minimum Supported Rust Version (MSRV)
+
+This text documents the MSRV policy used in the crates maintained by the RTFM developers.
+
+- Changing the MSRV of a crate is a breaking change and requires a semver bump:
+  minor version bump if the crate is pre-1.0 and a major version bump if the
+  crate is (post-)1.0.
+
+- Cargo features are allowed to depend a on Rust version greater than the MSRV,
+  even a nightly compiler. For example, a "const-fn" can bump the required
+  version to 1.34.0 (effectively, nightly channel at the time of writing).
+
+- When doing a semver bump (i.e. minor version bump in pre-1.0 crates), for
+  whatever reason, the team in charge of the crate should consider bumping the
+  MSRV as well.
+
+- The MSRV will be documented in the crate level documentation of the crate,
+  like so:
+
+``` markdown
+# Minimum Supported Rust Version (MSRV)
+
+This crate is guaranteed to compile on stable Rust 1.31 and up. It *might*
+compile with older versions but that may change in any new patch release.
+```
+
+- The MSRV will be tested in the CI of the crate as a separate build job, like
+  so:
+
+``` yaml
+matrix:
+  include:
+      # MSRV
+    - env: TARGET=thumbv7m-none-eabi
+      rust: 1.31.0
+
+    - env: TARGET=thumbv7m-none-eabi
+      rust: stable
+
+    - env: TARGET=thumbv7m-none-eabi
+      rust: beta
+
+      # etc.
+```

ops/nominate.md

@@ -0,0 +1,6 @@
+# Nominating rust-lang/* issues
+
+This document describes the process of "nominating" Cargo, compiler and `std`/`core`
+library issues to their respective Rust teams.
+
+A nominated issue will normally be forwarded to the Rust Embedded WG.

ops/post-transfer.md

@@ -0,0 +1,125 @@
+# Post transfer TODO list
+
+## Travis CI
+
+Browse to https://travis-ci.org/rtfm-rs/repo-name/settings and make sure that "Build pushed
+pull requests" is enabled.
+
+
+## Source
+
+Push a commit to `master` that does the following:
+
+- Creates `.github/CODEOWNERS` with the following contents:
+
+``` text
+* rtfm-rs/team-name collaborator-name another-collaborator
+```
+
+- Adds a copy of `CODE_OF_CONDUCT.md`. Don't forget to adjust the team name and associated
+  link accordingly.
+
+- Modifies `.travis.yml` to:
+  - Allow builds on these three branches. `staging` and `trying` are required by bors. We include
+    `master` to have builds on pushed PRs.
+
+``` yaml
+branches:
+  only:
+    - master
+    - staging
+    - trying
+```
+
+  - Prevent builds on changes to master. This is to prevent testing a PR *twice*: one build is
+    required to land the PR, but when the changes are merged into master we want to avoid that
+    second build.
+
+``` yaml
+matrix:
+  include:
+    - env: TARGET=thumbv6m-none-eabi
+      # add this `if` ...
+      if: (branch = staging OR branch = trying) OR (type = pull_request AND branch = master)
+
+    - env: TARGET=thumbv7m-none-eabi
+      # ... to all the elements of the build matrix
+      if: (branch = staging OR branch = trying) OR (type = pull_request AND branch = master)
+```
+
+- Mention the Code of Conduct and which team owns this repository in the README
+
+``` markdown
+# project-name
+
+> description of the project
+
+<!-- TODO add this -->
+
+This project is developed and maintained by the [RTFM team][team].
+
+<!-- ... omitting stuff in between ... -->
+
+<!-- TODO add this -->
+
+## Code of Conduct
+
+Contribution to this crate is organized under the terms of the [Rust Code of
+Conduct][CoC], the maintainer of this crate, the [RTFM team][team], promises
+to intervene to uphold that code of conduct.
+
+[CoC]: CODE_OF_CONDUCT.md
+[team]: https://github.com/orgs/rtfm-rs/teams/devs
+```
+
+- If the repository uses CI, configure bors. Add a `.github/bors.toml` file with these contents:
+
+``` toml
+block_labels = ["needs-decision"]
+delete_merged_branches = true
+required_approvals = 1
+status = ["continuous-integration/travis-ci/push"]
+```
+
+## Bors
+
+If the repository uses CI, update bors settings.
+
+- Browse to https://app.bors.tech/repositories, click on rtfm-rs/repo-name and then switch
+  to the "Settings" tab.
+
+- Synchronize both "Reviewers" and "Members" to people with "Push" (write) access to the
+    repository.
+
+## Repository
+
+Update the repository settings.
+
+- Browse to https://github.com/rtfm-rs/repo-name/settings and switch to the "Collaborators &
+  teams" tab.
+
+- Add the team that will oversee the project and give them "Admin" permissions.
+
+- The previous owner and old collaborators should have "Write" permissions.
+
+- Now switch to the "Branches" tab and add a branch protection rule for `master` with the
+  following settings:
+
+  - [x] Require pull requests reviews before merging
+    - [x] Dismiss stale pull request approvals when new commits are pushed
+    - [x] Require review from Code Owners
+
+  - [x] Require status checks to pass before merging (NOTE omit if not using CI)
+    - [x] bors (NOTE if bors doesn't appear here you will have to make a dummy PR, `bors r+` it
+      and then close it. This will make bors visible in this list)
+
+  - [x] Include administrators
+
+## crates.io
+
+If applicable, add new owners to crates.io. Have the current owner add the team that's receiving
+the crate as a team owner.
+
+```
+$ cargo owner --add github:rtfm-rs:team-name
+```