Comments inline: 2010/8/17 Karsten Wade - [email protected]: > On Mon, Aug 16, 2010 at 08:05:57PM -0400, Matthew Jadud wrote: >> 2010/8/16 Karsten Wade <[email protected]>: >> > Thoughts? >> >> My biggest concerns, when editing version 0.8, were that: >> >><snip> >> >> I remain concerned about the authoring environment -- perhaps because >> I don't understand it. With version control, you can submit patches, >> and they can be reviewed and discussed. On the wiki, there is a live >> environment that can neither be reviewed before submission nor >> "branched" in multiple directions. I'm hesitant to contribute to the >> process simply because I think a lot of the text needs >> revision/expansion/clarification, but I'm not an author. And since I >> can't "submit a patch" and discuss it with anyone, I simply have to >> edit the one live master environment, and hope that the changes are >> acceptable. While Greg had encouraged me to "be bold" during the >> sprint, I was mostly working on his chapters at the time, and I don't >> know if all the authors really feel the same way about their words >> ("hey, you completely rewrote those paragraphs!") as many people feel >> about their code ("wow! you made it 100 lines shorter and 3x as >> fast!"). > > I'm going to go read the rest of this thread, then I might come back > here with more on this topic. Just some general points: > > * There are ways with wiki tools to get more of what you are looking > for. >
Since the wiki based processes are not enforced by a tool, I feel there needs to be a documented set of "Rules of Engagement" so we can all contribute efficiently. > * By reviewed before submission, I presume you mean "reviewed by > others" not by yourself. You can use the practice of putting change > ideas in your user namespace, e.g. [[user:Jadudm/Foo_change]]. If > you want a diff, you paste in the original content, save it, then > make the change, save that, and the history shows a diff of the > two. Think of it like an SCM clone. This sequence of actions (copy, paste, save, then edit) are what I'm talking about as part of the "Rules of Engagement". If the contributor doesn't have any experience using a wiki as a Source Code Manager (SCM), that copy, let alone the first save is not an obvious requirement. > > * If we can get some progress on the tool that Ian and I dreamed on, > we can get every change on a watched page captured and sent to > email. MediaWiki, by default, sends one change for a watched page, > and does not send any other until you visit that page. That's from > MediaWiki culture that doesn't work as well in environments used to > diff and patch review via mailing list. Ian's tool would resolve > that to make it easier to watch and review on the live page. > <snip> > > My concern about using any other tool than a wiki is the significant > increase in barriers to contribution. I'm confident it's easier to > fix our concerns and usage of the wiki, let's see if we can make some > big improvements on the edit and writing workflow. > Barriers to contribution should not be removed if chaos ensues. There needs to be enough control that the neophyte does not destroy the work of the veterans. Please provide supporting information for your confidence. >> Thoughts? > > We want to enable "edit as you see it written" as well as "edit in > batches". I'd like to get more of the former this time so we can > correct each other before we get too much content plowed, watered, and > grown. > Planting in weedy compost is counter-productive. Let's be careful to properly prepare the soil. >> I have other writing I should be doing at this stage, and classes >> start in a week... but these were the concerns I had when I was >> working on the book before, and they're the concerns I still have, so >> I thought I'd share them, and hope someone can set me straight/clarify >> any confusion I might have. > > Excellent material, thanks. > > - Karsten _______________________________________________ tos mailing list [email protected] http://teachingopensource.org/mailman/listinfo/tos
