On Sat, Mar 28, 2015 at 09:36:50PM -0400, Jefry Lagrange wrote:
Hello everyone,
I found myself thinking about the process of proposing and editing xeps that
the xsf implements. I think there are some improvements that could be made
in order to make the process easier.
These are the main areas which I think are problematic with the current way
of doing things:
* git has a learning curve.
* xml has a learning curve.
* scripts are necessary to convert the xml to readable documents.
* Everything is tracked in the same project (scripts, templates,
xeps). XEPs aren't tracked as individual projects.
These problems aren't that grave, after all, most of us are developers.
However, I think it is worthwhile to explore alternatives to make it easier.
I spent the past week working on a wiki page that closely resembles the look
and feel of xeps.
Here is the url: http://jlagrange.net/wiki/index.php/Category:Extensions
In that week, I learned that by developing your own mediawiki skins and
extensions, you are able to make a wiki look however you like.
Because wikis were made specifically to track and modify documents, they
have some features could be useful for us.
* view and compare history of changes online
* user management to allow authors to modify their xeps and nothing
more. Or to allow trusted users to help Peter.
* rss of changes
* easier to edit and see the results without using scripts to convert
it to html
* discussion pages for each xep
At the very least it could serve a way to make quick prototypes and get
feedback.
Hello Jefry,
Making the XEP creation/edition process more accessible is a worthwhile
endeavour in my opinion. However, while the wiki format does have its
uses and advantages, I am not sure it would be a great fit for XEPs.
I want to address several points:
- git has a learning curve: yes, but git is not required at all for
proposing and editing xeps, you only need to clone the repo and
everything afterwards can be done without git.
- XML has a learning curve, but I would argue that people submitting
XMPP extensions are already past the required level ;). More to the
point, the only XML required while writing a XEP is some bare-bones
XHTML, and writing the metadata.
- Everything is tracked in the same project. Yes, I agree, but the
consensus seems to be that this isn’t an issue, as there aren’t too
many changes happening, and maintaining a separate history for each
XEP would be only more maintenance overhead, currently.
- XEPs already have online diffs
What I find lacking, or counter-intuitive, in a wiki-powered solution:
- The very ability to get all XEP sources in plain text, like we
currently can.
- Reviewing changes: wikis have this feature, but this would require to
create several pages per XEP, in order to have the author edit a copy
of the extension, then having people review them, and finally editors
can move the copy to the “final” page. This is important for the
publishing process, because non-editors shouldn’t be able to edit
published documents.
- Mandatory web interface (this is the biggest issue, for me), both for
reviews, discussions, and submissions
What I could appreciate in a wiki solution:
- RSS/Atom feeds of changes
- Centralized discussions: the mailing-list is nice to have exchanges,
but after some time it becomes gruesome to aggregate all that was said
on a particular extension.
- Possible web-based edition for quick edits to the documents, with
instant visual feedback.
(Please don’t think that I’m overly negative, I’m just writing down some
quick thoughts)
--
Mathieu Pasquet (mathieui)
pgpPpeL5bvUwL.pgp
Description: PGP signature
