Обсуждение: Colons in wiki page titles, and commit fest page names
I don't know how the page naming like Todo:Detail and CommitFest:March page naming got started, but it is not how other mediawiki sites use it. I think Todo/Detail and CommitFest/March would be more usual. Then you could also create a CommitFest index page and have natural path names. While some change might be pending, I think it'd also be forward looking to put year numbers in the commit fest page names. Any objections to making these changes?
On Mon, 21 Apr 2008, Peter Eisentraut wrote:
> I don't know how the page naming like Todo:Detail and CommitFest:March page
> naming got started, but it is not how other mediawiki sites use it. I think
> Todo/Detail and CommitFest/March would be more usual. Then you could also
> create a CommitFest index page and have natural path names.
>
> While some change might be pending, I think it'd also be forward looking to
> put year numbers in the commit fest page names.
>
> Any objections to making these changes?
+1
Regards, Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83
On 4/21/08, Peter Eisentraut <peter_e@gmx.net> wrote: > I don't know how the page naming like Todo:Detail and CommitFest:March page > naming got started, but it is not how other mediawiki sites use it. I think > Todo/Detail and CommitFest/March would be more usual. Then you could also > create a CommitFest index page and have natural path names. The colons are used for namespacing in mediawiki - they can help with searching and auto-indexing for example. /D
Peter Eisentraut wrote: > I don't know how the page naming like Todo:Detail and CommitFest:March page > naming got started, but it is not how other mediawiki sites use it. I think > Todo/Detail and CommitFest/March would be more usual. Then you could also > create a CommitFest index page and have natural path names. I came up with CommitFest:xxx out of thin air. If it has different semantics for mediawiki than this, I have no objection to changing it. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
On Mon, 21 Apr 2008, Peter Eisentraut wrote: > I don't know how the page naming like Todo:Detail and CommitFest:March > page naming got started, but it is not how other mediawiki sites use it Those pages are all items in a larger category, and that's how the subpages in a category are displayed. This is standard usage if you're on a site with heavy categorization. Look at http://wiki.postgresql.org/wiki/Category:Help for an example of it being used properly by an intrinsic page. > I think Todo/Detail and CommitFest/March would be more usual. Then you > could also create a CommitFest index page and have natural path names. Ultimately what could happen here is that pages like the CommitFest ones only need to get tagged with the appropriate category set, and then a category summary page can automatically include all of them rather than someone having to keep a current summary page up to date. Unfortunately, the current state of the wiki used some elements of that practice but didn't do everything correctly. Some of the naming artifacts are used but we're not getting the advantages of page generation yet. The proper fix here is to correct/improve the category and/or namespace structure, which may naturally end up having categorized pages with a : in the concatenated title. I think stepping away from that standard just to make titles prettier right now would be a waste of your time, and it may end up being a counterproductive move in the long run anyway. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Am Montag, 21. April 2008 schrieb Greg Smith: > Those pages are all items in a larger category, and that's how the > subpages in a category are displayed. This is standard usage if you're on > a site with heavy categorization. Look at > http://wiki.postgresql.org/wiki/Category:Help for an example of it being > used properly by an intrinsic page. I have finally found a presumably authoritative source about this: http://wiki.postgresql.org/wiki/Help:Namespaces The take-home message is, if the page is a content page (in our case, it is about PostgreSQL), then its name shouldn't contain a colon. Creating categories for pages, as you describe, could also be useful, but I think it is independent of the page naming.
On Mon, 21 Apr 2008, Peter Eisentraut wrote: > Creating categories for pages, as you describe, could also be useful, but I > think it is independent of the page naming. I bring it up because the current naming for some pages includes things that might be properly replaced by either categorization or namespaces, rather than continuing to include that detail in the name of the page. Page renaming is annoying enough in MediaWiki that you don't want to make several passes at it, better to decide exactly what to do and rename only once. > I have finally found a presumably authoritative source about this: > http://wiki.postgresql.org/wiki/Help:Namespaces And that suggests using Namespaces as a tool for organizing the main content isn't a recommended practice. As I look into this more I keep returning to categories as the preferred way to organize things. > The take-home message is, if the page is a content page (in our case, it > is about PostgreSQL), then its name shouldn't contain a colon. I'm with you here. All of the pages with colons on their names will eventually need to be renamed to remove them. I just think it's better to fix the categorization first, so people see the right way to do what the original writer trying to handle with colons, then do the rename. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
On Tue, Apr 22, 2008 at 4:47 AM, Greg Smith <gsmith@gregsmith.com> wrote: > I'm with you here. All of the pages with colons on their names will > eventually need to be renamed to remove them. I just think it's better to > fix the categorization first, so people see the right way to do what the > original writer trying to handle with colons, then do the rename. > So, what naming scheme should we go with? I guess I would lean towards "CommitFest YYYY-MM" for easy lexical sorting. Cheers, BJ
On Tue, 22 Apr 2008, Brendan Jurd wrote: > So, what naming scheme should we go with? I guess I would lean > towards "CommitFest YYYY-MM" for easy lexical sorting. I don't know. Maybe that is a good format. Maybe we should be naming them "8.4 CommitFest 1,2,3". This whole Year/Month format presumes a schedule that may or may not happen. For example: the next CommitFest is named "May 2008" right now. But what if it isn't then? Maybe some people end up on vacation and the whole thing slips a month. If the page was named "CommitFest 8.4-2" instead that problem goes away (but lexical sorting falls apart circa 10.0-1). I haven't thought about all this enough to have a good answer yet. And that's really the point: I don't think anybody else has either, because this hasn't been happening for long enough yet. As time goes by, there will be more information to help guide this sort of decision. There is nothing going on here that relies on this being cleaned up right now, and the longer that's put off the more input will be around on how to do it. One interesting property of content is that if you generate a bunch of it, it's a whole lot easier to organize that than it is to predict how to organize in advance. I didn't have any idea what the entry page for the developer's section should look like until the other day, when I sat down with all the available content pages and then struggled for a bit with how to organize them usefully. Didn't have a clue how to fit all that together until there was a critical mass of pages written, then I was able to play with the pieces for a bit until I fit them together in a useful way. That's always how this sort of thing goes. Similarly, there are parts of the CommitFest structure that are going to need at least one more round before it's clear what the best way to handle things is. This is why I'd prefer to do as little pre-organization as possible right now. I think your time, for example, would be better spent on the neat template work you've been doing--which has a direct, functional improvement in how people do the CommitFest work--rather than worrying about trivia like how the names will one day need to be changed in order to accomidate CommitFest name clashes that can't possibly exist this year. If it's not clearly impacting how people work, forget about it for now. "Premature optimization is the root of all evil" --Tony Hoare -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Greg Smith <gsmith@gregsmith.com> writes:
> On Tue, 22 Apr 2008, Brendan Jurd wrote:
>> So, what naming scheme should we go with? I guess I would lean
>> towards "CommitFest YYYY-MM" for easy lexical sorting.
> I don't know. Maybe that is a good format. Maybe we should be naming
> them "8.4 CommitFest 1,2,3". This whole Year/Month format presumes a
> schedule that may or may not happen. For example: the next CommitFest is
> named "May 2008" right now. But what if it isn't then? Maybe some people
> end up on vacation and the whole thing slips a month. If the page was
> named "CommitFest 8.4-2" instead that problem goes away (but lexical
> sorting falls apart circa 10.0-1).
Well, naming them after version numbers is doomed to fail even sooner
than that --- what happens when we decide that, say, 8.5 is going to be
called 9.0 instead? Those sorts of decisions have always been made at
the ends of release cycles, so you'd be stuck with retroactively
renaming the pages.
I think the year/month naming idea is fine, at least for as far ahead
as we can see at the moment. There's no intention of allowing the
commit fests to slip.
> ... If it's not clearly impacting how people work, forget about it
> for now.
Agreed.
regards, tom lane
On Wed, Apr 23, 2008 at 12:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> On Tue, 22 Apr 2008, Brendan Jurd wrote:
>> So, what naming scheme should we go with? I guess I would lean
>> towards "CommitFest YYYY-MM" for easy lexical sorting.
>
> I think the year/month naming idea is fine, at least for as far ahead
> as we can see at the moment. There's no intention of allowing the
> commit fests to slip.
>
The YYYY-MM naming convention seems to have been a success, so while I
was doing some cleanup on the wiki this evening I decided to go ahead
and rename the CommitFest pages by changing the colons to spaces. For
example,
CommitFest:2008-09 => CommitFest 2008-09
In each case, there is a redirect page left behind for those who have
static bookmarks to particular commitfests.
Meanwhile, I've manually resolved double-redirects like the old
CommitFest:{March,May,July} pages and updated all the pages which
reference the commitfest pages directly.
Apart from the orphaned redirects, I don't think we have any pages
left with "CommitFest:" in the name.
Cheers,
BJ