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
