Skip to content

Commit

Permalink
Ran https://prettier.io/ command on all markdown. (cloudevents#411)
Browse files Browse the repository at this point in the history 
* Ran pretter.io command on all markdown.

Signed-off-by: Scott Nichols <[email protected]>

* fix wacky markdown format.

Signed-off-by: Scott Nichols <[email protected]>

* reapply linter.

Signed-off-by: Scott Nichols <[email protected]>
  • Loading branch information
@n3wscott
n3wscott authored and Doug Davis committed Mar 28, 2019
1 parent 61d8169 commit d36b0df
Show file tree
Hide file tree
Showing 27 changed files with 1,780 additions and 1,707 deletions.
48 changes: 24 additions & 24 deletions CONTRIBUTING.md
View file
Original file line number Diff line number Diff line change
@@ -1,37 +1,37 @@
# Contributing to CloudEvents

This page contains information about reporting issues, how to suggest changes
as well as the guidelines we follow for how our documents are formatted.
This page contains information about reporting issues, how to suggest changes as
well as the guidelines we follow for how our documents are formatted.

## Table of Contents
* [Reporting an Issue](#reporting-an-issue)
* [Suggesting a Change](#suggesting-a-change)
* [Spec Formatting Conventions](#spec-formatting-conventions)

- [Reporting an Issue](#reporting-an-issue)
- [Suggesting a Change](#suggesting-a-change)
- [Spec Formatting Conventions](#spec-formatting-conventions)

## Reporting an Issue

To report an issue, or to suggest an idea for a change that you haven't
had time to write-up yet, open an
[issue](https://github.com/cloudevents/spec/issues). It is best to check
our existing [issues](https://github.com/cloudevents/spec/issues) first
to see if a similar one has already been opened and discussed.
To report an issue, or to suggest an idea for a change that you haven't had time
to write-up yet, open an [issue](https://github.com/cloudevents/spec/issues). It
is best to check our existing
[issues](https://github.com/cloudevents/spec/issues) first to see if a similar
one has already been opened and discussed.

## Suggesting a Change

To suggest a change to this repository, submit a [pull
request](https://github.com/cloudevents/spec/pulls)(PR) with the complete
To suggest a change to this repository, submit a
[pull request](https://github.com/cloudevents/spec/pulls)(PR) with the complete
set of changes you'd like to see. See the
[Spec Formatting Conventions](#spec-formatting-conventions) section for
the guidelines we follow for how documents are formatted.
[Spec Formatting Conventions](#spec-formatting-conventions) section for the
guidelines we follow for how documents are formatted.

Each PR must be signed per the following section.

### Assigning and Owning work

If you want to own and work on an issue, add a comment or “#dibs” it asking
about ownership. A maintainer will then add the Assigned label and modify
the first comment in the issue to include `Assigned to: @person`

about ownership. A maintainer will then add the Assigned label and modify the
first comment in the issue to include `Assigned to: @person`

### Sign your work

Expand Down Expand Up @@ -88,8 +88,8 @@ Use your real name (sorry, no pseudonyms or anonymous contributions.)
If you set your `user.name` and `user.email` git configs, you can sign your
commit automatically with `git commit -s`.

Note: If your git config information is set properly then viewing the
`git log` information for your commit will look something like this:
Note: If your git config information is set properly then viewing the `git log`
information for your commit will look something like this:

```
Author: Joe Smith <[email protected]>
Expand All @@ -100,13 +100,13 @@ Date: Thu Feb 2 11:41:15 2018 -0800
Signed-off-by: Joe Smith <[email protected]>
```

Notice the `Author` and `Signed-off-by` lines match. If they don't
your PR will be rejected by the automated DCO check.
Notice the `Author` and `Signed-off-by` lines match. If they don't your PR will
be rejected by the automated DCO check.

## Spec Formatting Conventions

Documents in this repository will adhere to the following rules:
* Lines are wrapped at 80 columns (when possible)
* Specifications will use [RFC2119](https://tools.ietf.org/html/rfc2119)
keywords to indicate normative requirements

- Lines are wrapped at 80 columns (when possible)
- Specifications will use [RFC2119](https://tools.ietf.org/html/rfc2119)
keywords to indicate normative requirements
171 changes: 85 additions & 86 deletions GOVERNANCE.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,121 +5,120 @@ project will manage this repository.

## Meetings

In order to provide equitable rights to all members,
the following process will be followed:

* Official conference calls will be announced at least a week in advance.
* Official face-to-face meetings will be announced at least 4 weeks in
advance.
* Proposed changes to any document will be done via a Pull Request (PR).
* PRs will be reviewed during official meetings, but off-line reviews
(LGTMs, NOT LGTMs) and comments are strongly encouraged to gauge the
group's opinion on the proposed change prior to the meeting.
* During meetings, priority will be given to PRs that appear to be ready for
a vote over those that appear to require discussions.
* PRs should not be merged if they have had substantial changes made within
two days of the meeting.
Rebases, typo fixes, etc. do not count as substantial.
Note, administrivia PRs that do not materially modify output documents
may be processed by admins as needed.
* Resolving PRs ("merging" or "closing with no action") will be done as a
result of a motion made during a meeting, and approved.
* Reopening a PR can be done if new information is made available, and a
motion to do so is approved.
* Any motion that does not have "unanimous consent" will result in a formal
In order to provide equitable rights to all members, the following process will
be followed:

- Official conference calls will be announced at least a week in advance.
- Official face-to-face meetings will be announced at least 4 weeks in advance.
- Proposed changes to any document will be done via a Pull Request (PR).
- PRs will be reviewed during official meetings, but off-line reviews (LGTMs,
NOT LGTMs) and comments are strongly encouraged to gauge the group's opinion
on the proposed change prior to the meeting.
- During meetings, priority will be given to PRs that appear to be ready for a
vote over those that appear to require discussions.
- PRs should not be merged if they have had substantial changes made within two
days of the meeting. Rebases, typo fixes, etc. do not count as substantial.
Note, administrivia PRs that do not materially modify output documents may be
processed by admins as needed.
- Resolving PRs ("merging" or "closing with no action") will be done as a result
of a motion made during a meeting, and approved.
- Reopening a PR can be done if new information is made available, and a motion
to do so is approved.
- Any motion that does not have "unanimous consent" will result in a formal
vote. See [Voting](#voting).

## Membership

There are three categories of project membership:
1 - Member. This is anyone who participates in the group's activities in any
of our communication channels (email, github issues/PRs, meetings, etc.).
No formal registration process is needed.
2 - Voting Member. See the (Voting)[#voting]section below for more information
on how the list of Voting Members are determined. During the normal
operations of the group, Voting Members and Members are the same with
respect to influence over the groups actions. The rights associated with
being a Voting Member only apply in the event of a formal vote being taken.
3 - Admin. Admins are Members of the group but have the ability to perform
administrative actions on behalf of the group. For example, manage the
website, github repos and moderate the meetings. Their actions should
be done with the knowledge and consent of the group. They also have the
ability to merge/close PRs, but only per the group's approval. See
the [OWNERS](OWNERS) file for the current list of Admins.

1. **Member.** This is anyone who participates in the group's activities in any
of our communication channels (email, github issues/PRs, meetings, etc.). No
formal registration process is needed.

2. **Voting Member.** See the (Voting)[#voting]section below for more
information on how the list of Voting Members are determined. During the
normal operations of the group, Voting Members and Members are the same with
respect to influence over the groups actions. The rights associated with
being a Voting Member only apply in the event of a formal vote being taken.

3. **Admin.** Admins are Members of the group but have the ability to perform
administrative actions on behalf of the group. For example, manage the
website, github repos and moderate the meetings. Their actions should be done
with the knowledge and consent of the group. They also have the ability to
merge/close PRs, but only per the group's approval. See the [OWNERS](OWNERS)
file for the current list of Admins.

## PRs

Typically, PRs are expected to meet the following criteria prior to being
merged:

* The author of the PR indicates that it is ready for review by asking for it
to be discussed in an upcoming meeting - eg. by adding it to the agenda
document.
* All comments have been addressed.
* PRs that have objections/concerns will be discussed off-line by interested
- The author of the PR indicates that it is ready for review by asking for it to
be discussed in an upcoming meeting - eg. by adding it to the agenda document.
- All comments have been addressed.
- PRs that have objections/concerns will be discussed off-line by interested
parties. A resolution, updated PR, will be expected from those talks.

## Voting

If a vote is taken during a meeting, the follow rules will be followed:

* There is only 1 vote per participating company, or nonaffiliated individual.
* Each participating company can assign a primary and secondary representative.
* A participating company, or nonaffiliated individual, attains voting rights
by having any of the entity's assigned representative(s), in aggregate,
attend 3 out of the last 4 meetings. The people listed as "primary" or
"alternate" for an entity can be changed no more than once a month and can
be changed by notifying one of the admins. The entity obtains voting rights
after the 3rd meeting, not during.
* Only members with voting rights will be allowed to vote.
* A vote passes if more than 50% of the votes cast approve the motion.
* Only "yes" or "no" votes count, "abstain" votes do not count towards the
- There is only 1 vote per participating company, or nonaffiliated individual.
- Each participating company can assign a primary and secondary representative.
- A participating company, or nonaffiliated individual, attains voting rights by
having any of the entity's assigned representative(s), in aggregate, attend 3
out of the last 4 meetings. The people listed as "primary" or "alternate" for
an entity can be changed no more than once a month and can be changed by
notifying one of the admins. The entity obtains voting rights after the 3rd
meeting, not during.
- Only members with voting rights will be allowed to vote.
- A vote passes if more than 50% of the votes cast approve the motion.
- Only "yes" or "no" votes count, "abstain" votes do not count towards the
total.
* Meeting attendance will be formally tracked
- Meeting attendance will be formally tracked
[here](https://docs.google.com/spreadsheets/d/1bw5s9sC2ggYyAiGJHEk7xm-q2KG6jyrfBy69ifkdmt0/edit#gid=0).
Members must acknowledge their presence verbally, meaning, adding yourself
to the "Attendees" section of the Agenda document is not sufficient.
* When a vote is called, unless all voting members have voted, the vote will be
Members must acknowledge their presence verbally, meaning, adding yourself to
the "Attendees" section of the Agenda document is not sufficient.
- When a vote is called, unless all voting members have voted, the vote will be
tallied no less than one week after calling the vote.
* Voting process:
* Comment on the PR: "YES VOTE", "NO VOTE", or "ABSTAIN".
* Any person is encouraged to vote with a statement of support or dissent to
- Voting process:
- Comment on the PR: "YES VOTE", "NO VOTE", or "ABSTAIN".
- Any person is encouraged to vote with a statement of support or dissent to
help undecided voters to reach a decision
* Comments are welcome from non-members
* Voting tally will reflect the above qualification and recorded in PR
- Comments are welcome from non-members
- Voting tally will reflect the above qualification and recorded in PR

## Release Process and Versioning

The specifications produced will adhere to the following:
* The versioning scheme used will follow [semver](https://semver.org/)
* All normative specifications, and the Primer, will be grouped together into
a single logical unit and released at the same time, at the same version
number. This is true regardless of whether each individual document actually
changed during the release cycle.

- The versioning scheme used will follow [semver](https://semver.org/)
- All normative specifications, and the Primer, will be grouped together into a
single logical unit and released at the same time, at the same version number.
This is true regardless of whether each individual document actually changed
during the release cycle.

Note that these rules do not apply to the
[documented extensions](documented-extensions.md).

To create a new release:
* Create a PR that modifies the [README](README.md), and all specifications
(ie. \*.md files) that include a version string, to the new release
version string.
* Merge the PR.
* Create a [new release](https://github.com/cloudevents/spec/releases/new):
* Choose a "Tag version" of the form: `vX.Y`, e.g. `v0.1`
* Target should be `master`, the default value
* Release title should be the same as the Tag - `vX.Y`
* Add some descriptive text, or the list of PRs that have been merged
since the previous release.
The git query to get the list commits since the last release is:
`git log --pretty=format:%s master...v0.1`.
Just replace "v0.1" with the name of the previous release.
* Press `Publish release` button
* Create an "announcement" highlighting the key features of the new release
and any potential noteworthy activities of the group:
* Send it to the mailing list
* Announce the release on our

- Create a PR that modifies the [README](README.md), and all specifications (ie.
\*.md files) that include a version string, to the new release version string.
- Merge the PR.
- Create a [new release](https://github.com/cloudevents/spec/releases/new):
- Choose a "Tag version" of the form: `vX.Y`, e.g. `v0.1`
- Target should be `master`, the default value
- Release title should be the same as the Tag - `vX.Y`
- Add some descriptive text, or the list of PRs that have been merged since
the previous release. The git query to get the list commits since the last
release is: `git log --pretty=format:%s master...v0.1`. Just replace "v0.1"
with the name of the previous release.
- Press `Publish release` button
- Create an "announcement" highlighting the key features of the new release and
any potential noteworthy activities of the group:
- Send it to the mailing list
- Announce the release on our
[twitter account](https://twitter.com/cloudeventsio)
* Add it to the "announcement" section of our
- Add it to the "announcement" section of our
[website](https://cloudevents.io/)

Loading

0 comments on commit d36b0df

Please sign in to comment.