Brad Knowles <[email protected]> writes: > I'm not entirely sure if it should be completely free online to anyone > who wants to see it, or if there should be some other process involved > -- I'm willing to be convinced either way, although my personal > tendency is to lean towards making it freely available under a typical > CC-NC-SA type of license (see > <http://creativecommons.org/licenses/by-nc-sa/3.0/>).
I think it needs to be 'free for all' if you want it to become an important industry document. I don't think the specific licence matters that much; you could even say that you (or lopsa) is the only organization that can print deadtree copies and I don't think that would slow it down much, as long as you keep it online for all. there is a much larger difference between having a login (even a free login) in front of a web document, vs having the document open and searchable by everyone than there is between charging $50 and $100 for a book. > A dead-tree version is also a necessity. I agree. reading things on paper is somehow... easier. > > I'd like to respond to the rest of what you said about > > mediawiki, but that's only important if you agree with me on the larger > > point, that we should put the 'tome of SysAdmin knowledge' online (as well > > as publishing it deadtree.) > > I think we're agreed on that much. I'd be interested to see what you > have to say about the rest. Personally, I really like mediawiki for small (under 10 people) projects, in a 'worse is better' sense. I use it because, well, there isn't any time to 'do it right' and putting it in mediawiki gets the info up quickly and easily, and the mediawiki markdown is close enough to plain text that you can mostly cut and paste the (markdown, not the html) into whatever other formatted thing you want. If you spot a mistake in someone else's work, fixing that mistake takes about 30 seconds. No complicated locking bs, you just hit edit, change it, submit. your change shows up in my rss feed reader. Having more structure is good. Structure can be imposed using mediawiki... personally, I'd like subdirectories, but eh, that's ok too. mediawiki structure can be good enough. I'm not experienced with other tools that make imposing structure easier. I think what we would be looking for there is something where one person, or a committee would lay out the structure, then you would have some kind of wiki-like editibility of the data. I'm certainly not married to mediawiki... it's just a good, easy, low barrier to entry tool. I think you underesimate the importance of the 'low barrierier to entry' bit even on a small project. I've got one guy working for me who has pretty bad grammar. I mean, worse than mine. He is a pretty good SysAdmin, and I suspect his gramatical problems are mostly because he hasn't tried to fix them. Anyhow, I expect everyone, including him, to use the mediawiki to document what they have done. Sure, the grammar is horrible at first, but that's solved by other people easily enough. And when you get down to it, even his unedited, raw documentation is better than nothing. (another trick I use with that person sometimes is I say "Figure out how to do X- then do it within a logged screen session. send me the log." I can then correctly document the procedure.) I am taking the approach of 'worse is better' because I don't have time to build the perfect gem. I could use about five kids like the one with bad grammar just to roll out the prgmr.com infrastructure I want. I'm currently doing 3 projects, each of which could really be called a full time job. I suspect, though, that this is likely to be common amongst the sort of people we want writing this. (unless you can find someone willing to take a year off and just write.) You want people who are actively doing stuff. If you look at my mediawiki, well, it's mostly unfinished. you have to go to 'all pages' to get anywhere useful. I have not yet imposed structure, and there are several pages that end with "and you follow these steps and it doesn't work. I have yet to figure it out." http://book.xen.prgmr.com I'm not sure that mediawiki is the right tool for LOPSA (the strong argument for mediawiki is the rather low barrier to entry.) but I do think that if such a book were to be made by LOPSA, I would suggest that using a tool with a low barrier to entry (something that makes it easy for you to just dump some working notes, and for someone else to do something useful with those working notes, or to do something useful with those notes at a later date. I know often my good work and my good writing come from very different mental states.) I would also suggest that you do not ignore contributions from users outside of LOPSA. Look at the mailing lists; People are happy to make little corrections (and little corrections there will be... every command we list is going to have about 40 footnotes explaining how it's different on system X. From my experience with the book of xen, people will find errors even in the stuff you know. It's easy to read what you meant to write.) I think that if your project is successfull, while you won't have as many editors as wikipedia, you certainly will have a whole lot. There are a lot of SysAdmins out there. Most can't contribute much, but that's true on wikipedia, too. Just correcting grammar or a command line switch can be useful, too. And hey, if someone figures out how to do something new, not currently in the tome, they can usefully add that. Key to success will be wrangling all that raw data into something useful. this is the wonderful thing about search; organization is much less important than it once was. (It's still important, especially for keeping data up to date. But not nearly as important as it was.) _______________________________________________ Discuss mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
