On Tue, Aug 17, 2010 at 08:48:01AM -0400, [email protected] wrote: > This sounds like the right step towards solving what I was concerned > about. I could copy a page to my own part of the wiki space, make > edits, and offer them up for discussion. Sadly, you don't get a > "diff", and change tracking is broken on each copy-paste, but it's a > step.
Just to circle back here, you can get a diff by making your first save the original source, then making our changes and saving. Agreed that the change tracking is broken, but think of this is a more like distributed version control. Your [[User:]] namespace is your clone of the parent (master) repository. When you make changes, they are only local, and you output your diff to a patch to send to an email. Of course, 'git' has all sorts of tools to make this easy. With the wiki, it's more manual. However, with software source code, the changes could be a few across 100 files, where these are more likely to be many changes to one or two files at a time. This means you make the manual process equivalent of 'git diff > mail' & 'git push master' only a few times per page, ideally. Change tracking is maintained by making the final changes manually to the source page, with the summary pointing back to Talk: pages and specific versions of pages in the [[User:]] namespace. > However, the question of what kinds of contributions are valued, and > when, is still important. (Or, I think it is, but I might be asking > the wrong question.) In general, all contributions are equally valued, with those doing the most work *no matter what the task* recognized by merit. In specific: * Writing or co-writing a chapter is a really valuable thing. (Writing) * Watching a few or all pages and helping the writers as they actually do the writing is a really valuable thing. (Editing) * Editing one chapter from top to bottom for voice, grammar, technical content, pedagogical approach, consistency, etc. are pretty much really valuable things. (Editing) * Editing the entire book for any of the above or other items is pretty much really valuable. (Editing) * Sourcing content from an upstream, working out the attribution and sustainability of using that content, and working it in to a chapter, up to and including voice tweaks is a very valuable thing. (E.g. chapters on licensing, culture, etc. that we need to produce.) (Writing) * Wrangling all of the writers and editors is a pretty valuable thing. * Using the textbook in a classroom and telling the students, "You are the textbook experts, we want to learn from you. If you have any feedback, here is the forum." That's a really, really valuable thing. * Using the textbook as a student (or thinking like a student?) and giving feedback on the forum is pretty valuable or wonderfully valuable, depending. :) * Helping improve our tooling, e.g. putting up an instance of NB for evaluation, is a pretty valuable thing. http://scripts.mit.edu/~sacha/nb/main.py Does that help? Or just confuse things? The other side of this is how we recognize contributions. Often, all the contributors to a book appear on the frontpiece of the book, inside the cover, right? If there were several Really Big Writers and Editors, they might be the only ones on the cover? Right now our _publication_ tool is Publican, which is based on DocBook XML. With that tool we have current output limitations (which we can fix), or we can choose an alternative. Attribution content appears on the front of the book like this: http://quaid.fedorapeople.org/TOS/Practical_Open_Source_Software_Exploration/html/ http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/index.html As you can see, each contributor gets an equal line, various content as input manually, and an order of contributors created manually and without guidance. In the past, we used to include a <colophon> (XML syntax) that had all the translators listed, for example. So, one approach is to use a <colophon> or <appendix> and put *all* the contributors there, from major writers to translators to copyeditors to people who fold napkins[1]. Then use the front page <author> section for the primary contributors. Then we just have to sort out who the primary contributors are. Which probably brings us back to your point. I propose, for this 0.8.1 release, that we put everyone in the primary <author> block, in alphabetical order by first name, and include role in the book production in the individual author blocks. If we're fortunate enough after that to have enough people and different enough contribution levels to warrant using the <colophon> approach, we could decide that then. Does that answer (some of) your question? - Karsten [1] http://www.robcottingham.ca/cartoon/archive/being-a-catalyst-in-communities-quaid-and-red-hat Folding napkins was Rob's great example, whatever I said in the talk was far more boring. (I had no idea he was in the audience, found that thanks to Google alert.) -- name: Karsten 'quaid' Wade, Sr. Community Gardener team: Red Hat Community Architecture uri: http://TheOpenSourceWay.org/wiki gpg: AD0E0C41
pgpumOsDoZ3UE.pgp
Description: PGP signature
_______________________________________________ tos mailing list [email protected] http://teachingopensource.org/mailman/listinfo/tos
