To /wiki or not to /wiki
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC8E4F86EC68CDC79652F507D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is the best place for this discussion ... sort of.[1] This topic is slightly complex, I'll sort things here in to some sections to help. =3D=3D Background =3D=3D With MediaWiki serving www.ovirt.org, that means we will be redirecting away from (and no longer using) wiki.ovirt.org. MW is going to provide the top-level pages, and standard MW configuration is to have everything appear after /wiki. It is not impossible to change this, but it has 3 main caveats: 1. Some stuff is going to be a bit harder - we have to resolve robots.txt and favicon.ico as not wiki articles, for example.[2] 2. We may get occasional bugs that people who use /wiki won't get. 3. mediawiki.org says, "this is not supported by the MediaWiki developers. So if your scheme doesn't work with a new MediaWiki version, you're on your own." Relevant sources: http://www.mediawiki.org/wiki/Manual:Wiki_in_site_root_directory http://www.mediawiki.org/wiki/Manual:Short_URL/Apache =3D=3D Options =3D=3D A. All site URLs are in the form of http://ovirt.org/wiki/Page_name B. All site URLs are in the form of http://ovirt.org/w/Page_name C. All site URLs are in the form of http://ovirt.org/Page_name =3D=3D My opinion =3D=3D I like option C - I want to see clean URLs that hide implementation detai= ls. My opinion on those concerns about upstream: that's open source. It's hard to do anything without having problems unique or rare due to your circumstances, getting bugs that others don't see who follow the out-of-the-box installation, and to wonder if you won't be able to get community support for the unusual configuration. As it happens, we've been running MediaWiki for the last year using the EPEL RPM -- which is not supported by the MediaWiki developers. When I went last Fall looking for help with something, #mediawiki told me to get rid of the RPM and use the ZIP instead, then come back for help. (The package maintainer (smooge) has been helpful in all cases instead, so I've been able to avoid having to go to the upstream developers for help again.) We have no guarantee that MediaWiki developers will support the OpenShift quickstart. It also does not use the ZIP out-of-the-box install, so it likely is unsupported. My conclusion here is, personally, I have to not care that we're going to be unsupported, since being supported is actually worse. (I'd rather run unsupported with a good RPM than supported with an unsigned ZIP.) Links from anywhere in the site that point to "the wiki" should point to a landing page e.g. [[OVirt wiki]] that organizes the pages on the wiki, exposing popular categories, etc. Thus, "the wiki" is not identified by a specific URL, it is identified by the type of content on the page - is it intended to be community documentation (a wiki) by it's category. =3D=3D Footnotes =3D=3D [1] I want to acknowledge as we start that part of Garrett's expertise that he brings to oVirt is the human-computer interface skillset. That may not be a skill that many others of us on this list have. Are there some folks in the rest of oVirt development we can invite to this discussion? UI or UX folks, for example? The reason why this matters is we want to separate our geeky-preferences from the way things tend to work best for a broad range of humans. For example, I love sub-domains, they work well for my brain - I'm so much happier with lists.ovirt.org/mailman/... than www.ovirt.org/mailman... But if Garrett told me that is not the best way to present the information for a wide audience, I would have to give that opinion high credence. Heck, I'm prepared to do some pretzel twists to make it happen, based on that. (I've also always secretly loathed that MediaWiki has the /wiki requirement.) [2] I suspect we can special-case them in the .htaccess file. --=20 Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 --------------enigC8E4F86EC68CDC79652F507D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iD8DBQFQo8RJ2ZIOBq0ODEERAnP3AKCe9M+f1DPGel86WohrLin9bj+IXgCfQY28 WevyHpdHMUAqjIbUqKz67PE= =nTjt -----END PGP SIGNATURE----- --------------enigC8E4F86EC68CDC79652F507D--
This is a multi-part message in MIME format. --------------030302070901080708030202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, What about using .htaccess or URL rewrite for solving this? regards, On 11/14/2012 05:18 PM, Karsten 'quaid' Wade wrote:
This is the best place for this discussion ... sort of.[1]
This topic is slightly complex, I'll sort things here in to some sections to help.
== Background ==
With MediaWiki serving www.ovirt.org, that means we will be redirecting away from (and no longer using) wiki.ovirt.org.
MW is going to provide the top-level pages, and standard MW configuration is to have everything appear after /wiki. It is not impossible to change this, but it has 3 main caveats:
1. Some stuff is going to be a bit harder - we have to resolve robots.txt and favicon.ico as not wiki articles, for example.[2]
2. We may get occasional bugs that people who use /wiki won't get.
3. mediawiki.org says, "this is not supported by the MediaWiki developers. So if your scheme doesn't work with a new MediaWiki version, you're on your own."
Relevant sources:
http://www.mediawiki.org/wiki/Manual:Wiki_in_site_root_directory http://www.mediawiki.org/wiki/Manual:Short_URL/Apache
== Options ==
A. All site URLs are in the form of http://ovirt.org/wiki/Page_name
B. All site URLs are in the form of http://ovirt.org/w/Page_name
C. All site URLs are in the form of http://ovirt.org/Page_name
== My opinion ==
I like option C - I want to see clean URLs that hide implementation details.
My opinion on those concerns about upstream: that's open source. It's hard to do anything without having problems unique or rare due to your circumstances, getting bugs that others don't see who follow the out-of-the-box installation, and to wonder if you won't be able to get community support for the unusual configuration.
As it happens, we've been running MediaWiki for the last year using the EPEL RPM -- which is not supported by the MediaWiki developers. When I went last Fall looking for help with something, #mediawiki told me to get rid of the RPM and use the ZIP instead, then come back for help. (The package maintainer (smooge) has been helpful in all cases instead, so I've been able to avoid having to go to the upstream developers for help again.)
We have no guarantee that MediaWiki developers will support the OpenShift quickstart. It also does not use the ZIP out-of-the-box install, so it likely is unsupported.
My conclusion here is, personally, I have to not care that we're going to be unsupported, since being supported is actually worse. (I'd rather run unsupported with a good RPM than supported with an unsigned ZIP.)
Links from anywhere in the site that point to "the wiki" should point to a landing page e.g. [[OVirt wiki]] that organizes the pages on the wiki, exposing popular categories, etc. Thus, "the wiki" is not identified by a specific URL, it is identified by the type of content on the page - is it intended to be community documentation (a wiki) by it's category.
== Footnotes ==
[1] I want to acknowledge as we start that part of Garrett's expertise that he brings to oVirt is the human-computer interface skillset. That may not be a skill that many others of us on this list have. Are there some folks in the rest of oVirt development we can invite to this discussion? UI or UX folks, for example?
The reason why this matters is we want to separate our geeky-preferences from the way things tend to work best for a broad range of humans. For example, I love sub-domains, they work well for my brain - I'm so much happier with lists.ovirt.org/mailman/... than www.ovirt.org/mailman... But if Garrett told me that is not the best way to present the information for a wide audience, I would have to give that opinion high credence. Heck, I'm prepared to do some pretzel twists to make it happen, based on that. (I've also always secretly loathed that MediaWiki has the /wiki requirement.)
[2] I suspect we can special-case them in the .htaccess file.
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Regards, Vinzenz Feenstra | Senior Software Engineer RedHat Engineering Virtualization R & D Phone: +420 532 294 625 IRC: vfeenstr or evilissimo Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com --------------030302070901080708030202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">Hi,<br> <br> What about using .htaccess or URL rewrite for solving this?<br> <br> regards,<br> <br> On 11/14/2012 05:18 PM, Karsten 'quaid' Wade wrote:<br> </div> <blockquote cite="mid:50A3C449.2000009@redhat.com" type="cite"> <pre wrap="">This is the best place for this discussion ... sort of.[1] This topic is slightly complex, I'll sort things here in to some sections to help. == Background == With MediaWiki serving <a class="moz-txt-link-abbreviated" href="http://www.ovirt.org">www.ovirt.org</a>, that means we will be redirecting away from (and no longer using) wiki.ovirt.org. MW is going to provide the top-level pages, and standard MW configuration is to have everything appear after /wiki. It is not impossible to change this, but it has 3 main caveats: 1. Some stuff is going to be a bit harder - we have to resolve robots.txt and favicon.ico as not wiki articles, for example.[2] 2. We may get occasional bugs that people who use /wiki won't get. 3. mediawiki.org says, "this is not supported by the MediaWiki developers. So if your scheme doesn't work with a new MediaWiki version, you're on your own." Relevant sources: <a class="moz-txt-link-freetext" href="http://www.mediawiki.org/wiki/Manual:Wiki_in_site_root_directory">http://www.mediawiki.org/wiki/Manual:Wiki_in_site_root_directory</a> <a class="moz-txt-link-freetext" href="http://www.mediawiki.org/wiki/Manual:Short_URL/Apache">http://www.mediawiki.org/wiki/Manual:Short_URL/Apache</a> == Options == A. All site URLs are in the form of <a class="moz-txt-link-freetext" href="http://ovirt.org/wiki/Page_name">http://ovirt.org/wiki/Page_name</a> B. All site URLs are in the form of <a class="moz-txt-link-freetext" href="http://ovirt.org/w/Page_name">http://ovirt.org/w/Page_name</a> C. All site URLs are in the form of <a class="moz-txt-link-freetext" href="http://ovirt.org/Page_name">http://ovirt.org/Page_name</a> == My opinion == I like option C - I want to see clean URLs that hide implementation details. My opinion on those concerns about upstream: that's open source. It's hard to do anything without having problems unique or rare due to your circumstances, getting bugs that others don't see who follow the out-of-the-box installation, and to wonder if you won't be able to get community support for the unusual configuration. As it happens, we've been running MediaWiki for the last year using the EPEL RPM -- which is not supported by the MediaWiki developers. When I went last Fall looking for help with something, #mediawiki told me to get rid of the RPM and use the ZIP instead, then come back for help. (The package maintainer (smooge) has been helpful in all cases instead, so I've been able to avoid having to go to the upstream developers for help again.) We have no guarantee that MediaWiki developers will support the OpenShift quickstart. It also does not use the ZIP out-of-the-box install, so it likely is unsupported. My conclusion here is, personally, I have to not care that we're going to be unsupported, since being supported is actually worse. (I'd rather run unsupported with a good RPM than supported with an unsigned ZIP.) Links from anywhere in the site that point to "the wiki" should point to a landing page e.g. [[OVirt wiki]] that organizes the pages on the wiki, exposing popular categories, etc. Thus, "the wiki" is not identified by a specific URL, it is identified by the type of content on the page - is it intended to be community documentation (a wiki) by it's category. == Footnotes == [1] I want to acknowledge as we start that part of Garrett's expertise that he brings to oVirt is the human-computer interface skillset. That may not be a skill that many others of us on this list have. Are there some folks in the rest of oVirt development we can invite to this discussion? UI or UX folks, for example? The reason why this matters is we want to separate our geeky-preferences from the way things tend to work best for a broad range of humans. For example, I love sub-domains, they work well for my brain - I'm so much happier with lists.ovirt.org/mailman/... than <a class="moz-txt-link-abbreviated" href="http://www.ovirt.org/mailman">www.ovirt.org/mailman</a>... But if Garrett told me that is not the best way to present the information for a wide audience, I would have to give that opinion high credence. Heck, I'm prepared to do some pretzel twists to make it happen, based on that. (I've also always secretly loathed that MediaWiki has the /wiki requirement.) [2] I suspect we can special-case them in the .htaccess file. </pre> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">_______________________________________________ Infra mailing list <a class="moz-txt-link-abbreviated" href="mailto:Infra@ovirt.org">Infra@ovirt.org</a> <a class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/infra">http://lists.ovirt.org/mailman/listinfo/infra</a> </pre> </blockquote> <br> <br> <pre class="moz-signature" cols="72">-- Regards, Vinzenz Feenstra | Senior Software Engineer RedHat Engineering Virtualization R & D Phone: +420 532 294 625 IRC: vfeenstr or evilissimo Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com</pre> </body> </html> --------------030302070901080708030202--
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2A2ACF5C8F9C4CF731E4D83E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/14/2012 08:33 AM, Vinzenz Feenstra wrote:
Hi, =20 What about using .htaccess or URL rewrite for solving this?
Thanks, yes, that is the way we handle the change technically. With OpenShift we'll use a .htaccess file. The question here is more of "should we make that change". Currently, the wiki follows the MediaWiki recommended format of having /wiki in the URL. - Karsten
regards, =20 On 11/14/2012 05:18 PM, Karsten 'quaid' Wade wrote:
This is the best place for this discussion ... sort of.[1]
This topic is slightly complex, I'll sort things here in to some sections to help.
=3D=3D Background =3D=3D
With MediaWiki serving www.ovirt.org, that means we will be redirectin= g away from (and no longer using) wiki.ovirt.org.
MW is going to provide the top-level pages, and standard MW configuration is to have everything appear after /wiki. It is not impossible to change this, but it has 3 main caveats:
1. Some stuff is going to be a bit harder - we have to resolve robots.txt and favicon.ico as not wiki articles, for example.[2]
2. We may get occasional bugs that people who use /wiki won't get.
3. mediawiki.org says, "this is not supported by the MediaWiki developers. So if your scheme doesn't work with a new MediaWiki versio= n, you're on your own."
Relevant sources:
http://www.mediawiki.org/wiki/Manual:Wiki_in_site_root_directory http://www.mediawiki.org/wiki/Manual:Short_URL/Apache
=3D=3D Options =3D=3D
A. All site URLs are in the form of http://ovirt.org/wiki/Page_name
B. All site URLs are in the form of http://ovirt.org/w/Page_name
C. All site URLs are in the form of http://ovirt.org/Page_name
=3D=3D My opinion =3D=3D
I like option C - I want to see clean URLs that hide implementation details.
My opinion on those concerns about upstream: that's open source. It's hard to do anything without having problems unique or rare due to your=
circumstances, getting bugs that others don't see who follow the out-of-the-box installation, and to wonder if you won't be able to get=
community support for the unusual configuration.
As it happens, we've been running MediaWiki for the last year using th= e EPEL RPM -- which is not supported by the MediaWiki developers. When I=
went last Fall looking for help with something, #mediawiki told me to get rid of the RPM and use the ZIP instead, then come back for help. (The package maintainer (smooge) has been helpful in all cases instead= , so I've been able to avoid having to go to the upstream developers for=
help again.)
We have no guarantee that MediaWiki developers will support the OpenShift quickstart. It also does not use the ZIP out-of-the-box install, so it likely is unsupported.
My conclusion here is, personally, I have to not care that we're going=
to be unsupported, since being supported is actually worse. (I'd rathe= r run unsupported with a good RPM than supported with an unsigned ZIP.)
Links from anywhere in the site that point to "the wiki" should point = to a landing page e.g. [[OVirt wiki]] that organizes the pages on the wik= i, exposing popular categories, etc. Thus, "the wiki" is not identified b= y a specific URL, it is identified by the type of content on the page - = is it intended to be community documentation (a wiki) by it's category.
=3D=3D Footnotes =3D=3D
[1] I want to acknowledge as we start that part of Garrett's expertise=
that he brings to oVirt is the human-computer interface skillset. That=
may not be a skill that many others of us on this list have. Are there=
some folks in the rest of oVirt development we can invite to this discussion? UI or UX folks, for example?
The reason why this matters is we want to separate our geeky-preferenc= es from the way things tend to work best for a broad range of humans. For=
example, I love sub-domains, they work well for my brain - I'm so much=
happier with lists.ovirt.org/mailman/... than www.ovirt.org/mailman...=
But if Garrett told me that is not the best way to present the information for a wide audience, I would have to give that opinion hig= h credence. Heck, I'm prepared to do some pretzel twists to make it happen, based on that. (I've also always secretly loathed that MediaWi= ki has the /wiki requirement.)
[2] I suspect we can special-case them in the .htaccess file.
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra =20 =20 =20 =20
Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra =20
--=20 Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 --------------enig2A2ACF5C8F9C4CF731E4D83E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iD8DBQFQo8md2ZIOBq0ODEERAka5AJ0VE/0CKcTzHjw+6pqCUSYlmT8qTACdH7tR mSKL55YB6JJczD+MEs3CeX0= =tInt -----END PGP SIGNATURE----- --------------enig2A2ACF5C8F9C4CF731E4D83E--
On Wed, 2012-11-14 at 08:41 -0800, Karsten 'quaid' Wade wrote:
On 11/14/2012 08:33 AM, Vinzenz Feenstra wrote:
Hi,
What about using .htaccess or URL rewrite for solving this?
Thanks, yes, that is the way we handle the change technically. With OpenShift we'll use a .htaccess file.
The question here is more of "should we make that change".
Currently, the wiki follows the MediaWiki recommended format of having /wiki in the URL.
I'd drop /wiki completely if technically possible and if not, then use something like /ovirt or /o Mike
- Karsten
regards,
On 11/14/2012 05:18 PM, Karsten 'quaid' Wade wrote:
This is the best place for this discussion ... sort of.[1]
This topic is slightly complex, I'll sort things here in to some sections to help.
== Background ==
With MediaWiki serving www.ovirt.org, that means we will be redirecting away from (and no longer using) wiki.ovirt.org.
MW is going to provide the top-level pages, and standard MW configuration is to have everything appear after /wiki. It is not impossible to change this, but it has 3 main caveats:
1. Some stuff is going to be a bit harder - we have to resolve robots.txt and favicon.ico as not wiki articles, for example.[2]
2. We may get occasional bugs that people who use /wiki won't get.
3. mediawiki.org says, "this is not supported by the MediaWiki developers. So if your scheme doesn't work with a new MediaWiki version, you're on your own."
Relevant sources:
http://www.mediawiki.org/wiki/Manual:Wiki_in_site_root_directory http://www.mediawiki.org/wiki/Manual:Short_URL/Apache
== Options ==
A. All site URLs are in the form of http://ovirt.org/wiki/Page_name
B. All site URLs are in the form of http://ovirt.org/w/Page_name
C. All site URLs are in the form of http://ovirt.org/Page_name
== My opinion ==
I like option C - I want to see clean URLs that hide implementation details.
My opinion on those concerns about upstream: that's open source. It's hard to do anything without having problems unique or rare due to your circumstances, getting bugs that others don't see who follow the out-of-the-box installation, and to wonder if you won't be able to get community support for the unusual configuration.
As it happens, we've been running MediaWiki for the last year using the EPEL RPM -- which is not supported by the MediaWiki developers. When I went last Fall looking for help with something, #mediawiki told me to get rid of the RPM and use the ZIP instead, then come back for help. (The package maintainer (smooge) has been helpful in all cases instead, so I've been able to avoid having to go to the upstream developers for help again.)
We have no guarantee that MediaWiki developers will support the OpenShift quickstart. It also does not use the ZIP out-of-the-box install, so it likely is unsupported.
My conclusion here is, personally, I have to not care that we're going to be unsupported, since being supported is actually worse. (I'd rather run unsupported with a good RPM than supported with an unsigned ZIP.)
Links from anywhere in the site that point to "the wiki" should point to a landing page e.g. [[OVirt wiki]] that organizes the pages on the wiki, exposing popular categories, etc. Thus, "the wiki" is not identified by a specific URL, it is identified by the type of content on the page - is it intended to be community documentation (a wiki) by it's category.
== Footnotes ==
[1] I want to acknowledge as we start that part of Garrett's expertise that he brings to oVirt is the human-computer interface skillset. That may not be a skill that many others of us on this list have. Are there some folks in the rest of oVirt development we can invite to this discussion? UI or UX folks, for example?
The reason why this matters is we want to separate our geeky-preferences from the way things tend to work best for a broad range of humans. For example, I love sub-domains, they work well for my brain - I'm so much happier with lists.ovirt.org/mailman/... than www.ovirt.org/mailman... But if Garrett told me that is not the best way to present the information for a wide audience, I would have to give that opinion high credence. Heck, I'm prepared to do some pretzel twists to make it happen, based on that. (I've also always secretly loathed that MediaWiki has the /wiki requirement.)
[2] I suspect we can special-case them in the .htaccess file.
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Hi, On 11/14/2012 05:18 PM, Karsten 'quaid' Wade wrote:
C. All site URLs are in the form of http://ovirt.org/Page_name
I prefer this.
Links from anywhere in the site that point to "the wiki" should point to a landing page e.g. [[OVirt wiki]] that organizes the pages on the wiki, exposing popular categories, etc. Thus, "the wiki" is not identified by a specific URL, it is identified by the type of content on the page - is it intended to be community documentation (a wiki) by it's category.
Yes, my concerns were mostly around the way that "wiki" has become synonymous in open source circles with "editable website", and if we avoided using the word altogether that we might lose some community editing energy. Once we have a clear path to becoming an editor, awareness that the website is a wiki that can be edited, and a way to protect certain pages from editing (which we do), then I'm happy. Cheers, Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
On Wed, Nov 14, 2012 at 08:18:17AM -0800, Karsten 'quaid' Wade wrote:
C. All site URLs are in the form of http://ovirt.org/Page_name
I like option C - I want to see clean URLs that hide implementation details.
+1 on clean URLs if possible.
My conclusion here is, personally, I have to not care that we're going to be unsupported, since being supported is actually worse. (I'd rather run unsupported with a good RPM than supported with an unsigned ZIP.)
+1 on not caring about support.
I've also always secretly loathed that MediaWiki has the /wiki requirement.
I always likes dokuwiki more than mediawiki, but always doubted it because mediawiki has a larger user base and people seem to have enough trouble using a wiki as it is.
participants (5)
-
Dave Neary -
Ewoud Kohl van Wijngaarden -
Karsten 'quaid' Wade -
Mike Burns -
Vinzenz Feenstra