|
1 | | -# Activity Streams 2.0 Editor's Drafts |
| 1 | +# Activity Streams 2.0 |
2 | 2 |
|
3 | | -Contributions to this specification are governed by the W3C |
4 | | -IPR Policy. Pull requests will be accepted only if the |
5 | | -submitter is a current member of the W3C Social WG but |
6 | | -issues can be opened by anyone. |
| 3 | +Activity Streams 2.0 (AS2) is a social data format. Its types represent activities, content objects, and actors like people or groups on the social web. |
7 | 4 |
|
8 | | -## Implementations |
| 5 | +It is an extensible format; the Activity Vocabulary provides a structure for social applications, but more focused or innovative objects can be represented in AS2 by extending the vocabulary. |
9 | 6 |
|
10 | | -Recent implementation summary: https://www.w3.org/2017/02/social/implementations/as2/ |
| 7 | +## Key Links |
11 | 8 |
|
12 | | -Please report your implementations and test results as a pull request on a new file in [implementation-reports](https://github.com/w3c/activitystreams/tree/master/implementation-reports), using the format of [template.md](https://github.com/w3c/activitystreams/blob/master/implementation-reports/template.md). |
| 9 | +* The [Core specification](https://www.w3.org/TR/activitystreams-core/) describes the basic structure of AS2 and the core classes like `Object` and `Link`. |
| 10 | +* The [Vocabulary specification](https://www.w3.org/TR/activitystreams-vocabulary/) expands on the core specification with definitions of several dozen activity and object types, as well as many properties of those types. |
| 11 | +* The [SocialCG](https://www.w3.org/Social/WG) is the W3C Social Web Working Group, which is the home of AS2. |
| 12 | +* [ActivityPub](https://www.w3.org/TR/activitypub/) is a protocol that uses AS2 for communication between social systems. |
| 13 | +* The [Activity Streams Primer](https://www.w3.org/wiki/Activity_Streams/Primer) includes some expanded examples and explanations of AS2. If it's unclear how to use a type or property, the primer is a good place to start. |
| 14 | +* The [Extensions registry](https://www.w3.org/wiki/Activity_Streams/Extensions) lists known extensions to AS2. |
| 15 | +* Popular extensions can be integrated into the AS2 vocabulary document, making them practically part of the spec. The [Extensions Policy](https://swicg.github.io/extensions-policy/) describes how to propose extensions for inclusion in AS2. |
| 16 | + |
| 17 | +## Editors |
| 18 | + |
| 19 | +The currently active editors of the AS2 specification(s) are: |
| 20 | + |
| 21 | +- [Evan Prodromou](https://github.com/evanp) |
| 22 | + |
| 23 | +## Supported deliverables |
| 24 | + |
| 25 | +These files are maintained by the editor(s) under the supervision of the SocialCG: |
| 26 | + |
| 27 | +* The Core specification. |
| 28 | +* The Vocabulary specification. |
| 29 | +* The JSON-LD context document. |
| 30 | +* The OWL ontology document. |
| 31 | + |
| 32 | +The documentation is primary; the JSON-LD context and OWL ontology follow from the documentation. |
| 33 | + |
| 34 | +Other documents included here are informational and provided on a best-effort basis, or to support the processes of the W3C. |
| 35 | + |
| 36 | +## Contributions |
| 37 | + |
| 38 | +Because AS2 is a W3C Recommendation, its published documents are stable and changes are highly controlled. If you'd like to contribute, the best way is to open a [GitHub issue](https://github.com/w3c/activitystreams/issues) or join the [SocialCG](https://www.w3.org/Social/WG) and participate in discussions there. |
| 39 | + |
| 40 | +Pull requests are generally *not* helpful, unless you're an editor or have been asked to submit a pull request by an editor. The editors are responsible for the content of the documents, and they will make changes based on the issues and discussions. |
| 41 | + |
| 42 | +AS2 provides the vocabulary for ActivityPub, but many of the protocol details are not part of AS2. Issues with the protocol and ActivityPub API should be created in the [ActivityPub repository](https://github.com/w3c/activitypub). If you're not sure, it's okay to open an issue in the AS2 repository and the editors will navigate it to the right place. |
| 43 | + |
| 44 | +## Processes |
| 45 | + |
| 46 | +### Questions and clarifications |
| 47 | + |
| 48 | +If you have a question about the specification(s), including text or terms that are unclear or ambiguous, please open a [GitHub issue](https://github.com/w3c/activitystreams/issues). |
| 49 | + |
| 50 | +Clarifying questions may influence future versions of the document, but they aren't usually treated as errors that need to be updated as errata. A typical resolution for a clarifying question is to add a page to the [Activity Streams Primer](https://www.w3.org/wiki/Activity_Streams/Primer). |
| 51 | + |
| 52 | +### Editorial changes |
| 53 | + |
| 54 | +If you find a textual error in the specification(s), please open a [GitHub issue](https://github.com/w3c/activitystreams/issues). Examples of textual errors: |
| 55 | + |
| 56 | +- Spelling mistakes |
| 57 | +- Grammar mistakes |
| 58 | +- Broken links |
| 59 | +- Incorrect references to other parts of the document |
| 60 | +- Semantic mistakes |
| 61 | +- Misleading or confusing language |
| 62 | +- Syntax errors in the JSON-LD of examples in the documents |
| 63 | + |
| 64 | +The process for making editorial changes is as follows: |
| 65 | + |
| 66 | +1. A GitHub issue is opened. |
| 67 | +2. Participants discuss the issue in the comments. |
| 68 | +3. The editor(s) open a pull request to add the correction to the ERRATA document. |
| 69 | +4. At a future meeting of the SocialCG, the editor(s) propose to accept the pull request. The SocialCG discusses the proposal and votes to accept or reject it. |
| 70 | +5. If it's accepted, the editor(s) merge the pull request and close the issue. |
| 71 | +6. The editor(s) update the editor's draft of the document to include the correction. |
| 72 | +7. Periodically, updated non-normative editorial changes are published as a new version of the document at the canonical URL. |
| 73 | + |
| 74 | +### Backwards-compatible changes |
| 75 | + |
| 76 | +Social networking changes every year, and AS2 is designed to be keep up with that pace of change. Backwards-compatible changes are those that don't break existing implementations of AS2. |
| 77 | + |
| 78 | +The most important type of backwards-compatible normative change is adding types and properties to the vocabulary. |
| 79 | + |
| 80 | +The primary way to create a backwards-compatible change is to create a new extension to Activity Streams 2.0. You can create a GitHub issue to discuss the extension idea, which can help with building consensus around the change. |
| 81 | + |
| 82 | +Extensions are documented on the [Extensions registry](https://www.w3.org/wiki/Activity_Streams/Extensions). Before starting a new extension, it's a good idea to check the registry to see if someone else has already created a similar extension. |
| 83 | + |
| 84 | +The [Fediverse Enhancement Proposals](https://codeberg.org/fediverse/fep) process is a lightweight collaboration process for creating and documenting Activity Streams 2.0 extensions (and other changes to the Fediverse). It's a good place to start if you're considering a backwards-compatible change. |
| 85 | + |
| 86 | +There are many ideas for backwards-compatible changes to ActivityPub that have not yet been written up as a FEP or other document. These are marked [Needs FEP](https://github.com/w3c/activitystreams/issues?q=is%3Aissue+label%3A%22needs-fep%22) in the ActivityPub GitHub issue repository, and contributors are welcome to [submit a FEP](https://codeberg.org/fediverse/fep/src/branch/main#submitting-a-fep) on the topic. Note that issues may be closed without the FEP being created; that does not mean that the FEP is no longer needed. |
| 87 | + |
| 88 | +Extensions that become popular can be integrated into the AS2 vocabulary document, making them practically part of the spec. The [Extensions Policy](https://swicg.github.io/extensions-policy/) describes how to propose extensions for inclusion in AS2. |
| 89 | + |
| 90 | +Future versions of the AS2 specification(s) may include popular extensions as part of the core specs; see below. |
| 91 | + |
| 92 | +### Non-backwards-compatible changes |
| 93 | + |
| 94 | +Non-backwards-compatible changes to the specification require chartering a new working group at the W3C. They also require making changes in dozens of ActivityPub implementations and tens of thousands of running servers. This is a lot of work and is not done lightly. |
| 95 | + |
| 96 | +Non-backwards-compatible changes include: |
| 97 | + |
| 98 | +- Making optional behaviour mandatory |
| 99 | +- Loosening requirements for existing types or properties |
| 100 | +- Deprecating types or properties |
| 101 | +- Removing types or properties from the vocabulary |
| 102 | + |
| 103 | +If you think a non-backwards-compatible change is necessary, please open a [GitHub issue](https://github.com/w3c/activitystreams/issues) to discuss it. It will be marked as a "next version" issue, so when a new working group is chartered, the issue can be considered for the new version of the specification(s). |
0 commit comments