Re: [Standards] wiki for xeps
On 29 Mar 2015, at 02:36, Jefry Lagrange jefry.re...@gmail.com 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. Hi Jefry, What’s your expected response to this? That is - are you posting it as a FYI thing for folks to look at, or are you proposing this as an update to XSF procedures? /K
Re: [Standards] wiki for xeps
Just as an experiment to see how the procedure could be improved. Of course, xsf could implement it if you are inclined to do it. Although, you'd have to be aware of the costs of doing that. On 30/03/15 16:55, Kevin Smith wrote: On 29 Mar 2015, at 02:36, Jefry Lagrange jefry.re...@gmail.com 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. Hi Jefry, What’s your expected response to this? That is - are you posting it as a FYI thing for folks to look at, or are you proposing this as an update to XSF procedures? /K
Re: [Standards] wiki for xeps
On 28/03/15 23:16, Mathieu Pasquet wrote: 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. This is possible either by extensions or by using third party converters. I think this is actually a common use case for a lot of mediawiki users. - 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. Actually I think you could configure mediawiki to have a queue of changes where the changes have to be approved by someone i.e. the editor. - Mandatory web interface (this is the biggest issue, for me), both for reviews, discussions, and submissions That's a feature not a bug =D. 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. Ultimately I agree with you. This is not needed as the current system is working fine. The time investment required to tidy up things with the wiki to make it transparent to the user, to use wiki templates instead of the xml ones, to fix formatting errors with inner links and tables, would be costly. But now that we have the discussion going. Those points that you mentioned are interesting (RSS/Atom would be amazing). (Please don’t think that I’m overly negative, I’m just writing down some quick thoughts) Not at all. I'm not invested in this. This is the result of me fooling around for a week.
[Standards] wiki for xeps
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. -- Jefry Lagrange
Re: [Standards] wiki for xeps
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
