(note that the path must point to the ``content`` subdirectory of the
Don’t forget to commit & push the changes to [xep-attic].
@ -115,28 +335,27 @@ New ProtoXEPs
@@ -115,28 +335,27 @@ New ProtoXEPs
this or ask the author to fix it).
- You may want to build the protoxep locally and ensure the HTML and PDF look
- Merge the PR as described in "Merging a PR". Once the email has been sent,
- Create a card for the protoxep on the [Council Trello] under "Proposed
- Attach the PR to the card, and comment on the PR with a link to the card,
thanking the author for their submission and letting them know that their XEP
will be voted on within the next two weeks.
- Merge the PR and add a link to the generated protoxep (does this happen
automatically yet?) to the card so that council can read it.
- Wait for the XEP to appear on xmpp.org and then log into the webserver, change
directories to `/home/xsf/xmpp-hg/extensions`, perform an `hg pull && hg
update` (yes, that's right) and run `inxep.py name approvingbody` (eg.
`./inxep.py pars council`).
Agendums" and add the PR to the [Council Tracking].
- Attach the PR to the card and link the generated HTML.
- Comment on the PR with a link to the card, thanking the author for their
submission and letting them know that their XEP will be voted on within the
next two weeks.
- If the council forgets and doesn't vote on the protoxep, pester them until
- If the council rejects the XEP, you're done (leave the XEP in the inbox and
inform the author of the councils decision).
Otherwise,see "Promoting a ProtoXEP".
inform the author of the councils decision). Otherwise, see
"Promoting a ProtoXEP".
Promoting a ProtoXEP
- Once the council approves a ProtoXEP, move it out of the inbox and into the
- It is easiest to start a new branch, in case you screw something up on the
- Once the council approves a ProtoXEP, *copy* it out of the inbox and into the
root, assigning it the next available number in the XEP series.
- Modify the `<number/>` element in the XML file to match.
- Set the version to `0.1` and the initials to `XEP Editor: xyz` (replacing
@ -144,10 +363,9 @@ Promoting a ProtoXEP
@@ -144,10 +363,9 @@ Promoting a ProtoXEP
- Remove the `<interim/>` element from the XML file if it is included.
- Set the status to `Experimental`.
- Add a reference to the XEP in `xep.ent`.
- Archive the first version of the XEP (TODO: this process is currently
changing; add a description when the dust has settled).
- Wait for the XEP to be published then log into the webserver and run
`announce.py` (TODO: Add an example here).
- Make a commit.
- Treat your branch as you would treat a [Ready to Merge] PR in "Merging a PR".
(you don’t need to create another branch though.)
@ -165,13 +383,64 @@ You can also refer to `xep-template.xml` for a recommended list of sections and
@@ -165,13 +383,64 @@ You can also refer to `xep-template.xml` for a recommended list of sections and
whether or not they are required.
For a helpful graph of how XEP promotion works, see [XEP-0001].
Merging a PR
Before Merging a PR, read the "General notes on making changes" section.
When you get to the point that the PR is [Ready to Merge], do the following:
1. Create a new branch off master called ``feature/xep-1234`` (if the PR
touches multiple XEPs, I call it ``feature/xep-0678,xep-0789``).
2. Merge all [Ready to Merge] PRs which affect the XEP(s) into that branch.
3. Resolve conflicts.
4. If the PRs introduced multiple revision blocks, squash it down to a single
revision block. Set "XEP Editor (initials)" as author of the revision block
and add the initials of the original PR authors to the changelog entries.
(If that doesn’t make sense to you, you’ll find plenty examples in the
5. Ensure that everything builds by performing a full docker build (see above).
(Once the docker build reaches the point where the XEPs are built, you can
switch branches and work on another PR.)
6. If the build passes, check that the generated files look sane by running the
7. Merge the PR into master. If you are working on independent changes to
multiple XEPs, you can merge them all in one go.
8. If you merged multiple things into master, re-do the docker build check.