On 7/30/08, Chad Wilson <[EMAIL PROTECTED]> wrote: >> Also agreed. I think this is part of a larger problem -- our overall >> docs are in disarray and could benefit from someone taking an active >> role as Documentation Chief and cleaning house a bit. We've also lost >> some WikiWardens who were directly involved in writing documentation, >> which makes this situation worse. A WikiWarden armed with transclusion >> rights would be in a good position to clean house here. >> >> Would anyone be interested in taking an active role in documentation >> for MusicBrainz? > > Due to my new privilege as a TransclusionEditor I am somewhat keen to take > some role in tidying this up. I am happy to be one of the "doers", but am a > bit unsure about the delegation aspects - it presumes that there are people > out there to delegate to, but I'm not sure many are interested in > documentation these days!
Documentation is right up my alley, but my wiki-fu is rather weak, which is one of the reasons I've never really tried to jump head into it. One of the things I really think we need, before proceeding anywhere, is a _total_ documentation audit; It's really difficult to get a handle on what changes affect what, which pages are now contradicting each other, because one got updated and another didn't, etc. So a list/table of at least: 1) What pages we have 2) Where else that page content is deferred to (most a 'what does this link to', but not always, sometimes the expectation is implicit that an editor should understand _this_ page in the context of _other_ but unlinked pages. That needs fixing) 3) What refers to or links to this page (the opposite of 2) 4) The status of every page present in 1) (proposed, official, out of date, useless bloat...) 5) Which ones have a discussion page attached 6) Which pages are wanted but not present My thinking here: The reason for 6 is obvious. Those obviously need to be written. For 5, we discussed on list, and decided getting the discussion off the guideline pages made them a lot clearer to general readers, and should be continued. That would give a list of pages where that work needs to be completed. Using 1, 2, 3 and 4, we could then work methodically through each page, and come up with a list of which ones are currently contradicting each other (whether implicitly or explicitly, this is something that comes up fairly often) and which ones are covering the same ground. > Previously, I have avoided editing documentation due to the quagmire that is > the approval and RFC/RFV process and what seems like differing opinions on > what to do with the wiki content. I've got into it a bit more in recent > months (adding missing EditTypes, fixing some Picard stuff and such) but I'd > love to get a framework set up whereby I can make some serious inroads to > completing the DonRedman/dmppanda/murdos work. I'm thinking, making a plan of how to proceed will be a lot easier, if we really understand what we've already got. If you think this is a good idea, I'm willing to take it on (and if I take it on, I'm obviously willing to add other 'measurements' that should be collected as it's being done.) > The issue at the moment is that the problem is too big. I think we need a > streamlined process for a period of time to try and clean out the bulk of > the old/outdated crud so that the time can gradually be spent more on > maintenance/improving/reviewing rather than restructuring/deleting/tidying. I agree totally. -- Lauri Watts _______________________________________________ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
