From: Anton v. S. <an...@ap...> - 2004-04-14 17:55:44
|
Francisco Solsona wrote: > Does this makes sense? is it doable? I think it's technically doable, but I'll check. Anton |
From: MJ R. <mj...@ds...> - 2004-04-22 02:03:13
|
On 2004-04-22 02:22:43 +0100 Francisco Solsona <so...@ac...> wrote: > Ummm... not so sure about the daft situation, but I can assure you > that there are people working already on several (albeit basic) > recipes. [...] So what is going on? I am being told contradicting things again. This makes me unhappy. 1. If this is an active book already and people are charging off in the wrong direction, then fine, you go get on with it and I'll shut up, bypassed. Having explored what is there a little more, getting that answer now is the end for me. I'll go do something else useful instead while you create big deferred project and editing work. Run, run, run off the clifftops and good luck adjusting the flight as you go. Never know: it might just work. 2. If this is a proof of concept, then great, let's get the concepts right soon. Editing and release production (input and output) need simplifying to fit the stated "lightweight" aim. Basic project monitoring questions need more knowledge of what the system can produce than I have. I seem to get a bit stuck with the way this is strangely like a wiki, but not a wiki. "PureWikiFans" was definitely the wrong name for me to use, eh? -- MJR/slef My Opinion Only and possibly not of any group I know. Please http://remember.to/edit_messages on lists to be sure I read http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ sl...@ja... Creative copyleft computing services via http://www.ttllp.co.uk/ |
From: Anton v. S. <an...@ap...> - 2004-04-22 08:03:14
|
MJ Ray wrote: > On 2004-04-22 02:22:43 +0100 Francisco Solsona <so...@ac...> wrote: > >> Ummm... not so sure about the daft situation, but I can assure you that there are people working already on several (albeit basic) recipes. [...] > > So what is going on? I am being told contradicting things again. This makes me unhappy. Sorry if I gave a misleading impression. Francisco's right, many recipes have been written, and continue to be written - see the WebChanges page for the most recent ones. What I meant about the "proof of concept" and so on is that if anyone doesn't like something that I or someone else does, then they should say so, suggest alternatives, etc. In the absence of that kind of feedback, we have all been moving forward. The questions you have raised have all been valid, and I think we want to address them all in some way or another, but so far nothing has been raised that seems to require us to halt progress until we've resolved more of the issues. For the record, if we do decide to shift direction before making the cookbook more public, I hereby volunteer to convert the recipes that have been written so far, into whatever new format we decide on. It really isn't that big a deal - it's the kind of thing you can do with some regexp scripts, which is exactly what I did to convert the original cookbook from WebIt. Whether there are 40 pages or 150 to convert doesn't really matter. > 1. If this is an active book already and people are charging off in the wrong direction, then fine, you go get on with it and I'll shut up, bypassed. The book is active in the sense that a few of the original Schematics members have been writing recipes. I don't see any charging off in the wrong direction. Questions like whether the cookbook should be annotation-based are pretty moot currently, given the limited group of authors involved, and given that they will all presumably be editors when the cookbook goes public. I'm perfectly willing to entertain the idea that we're going in a wrong direction, but to be convinced of that, I'd need to see alternatives. I'm really not sure what you're suggesting we should actually *do*. > Having explored what is there a little more, getting > that answer now is the end for me. I'll go do something else useful instead while you create big deferred project and editing work. Run, run, run off the clifftops and good luck adjusting the flight as you go. Never know: it might just work. I'm planning to do what I can to make it work. I think that's the real point here. > 2. If this is a proof of concept, then great, let's get the concepts right soon. Editing and release production (input and output) need simplifying to fit the stated "lightweight" aim. Compared to WebIt in CVS, we've already made a significant improvement in "lightweightness". The recipes that Francisco, Jens, Gordon and Noel have contributed testify to that. We do need to write up the process in a way that's geared towards people who haven't been involved from the beginning, and we'll be doing that. We'll also streamline the process where we can. Regarding output, I'm of the opinion that the cookbook's structure is likely to evolve even after it goes public. Producing an HTML version should be fairly straightforward using wget, as Noel suggested. An informal PDF version should be similarly simple, e.g. by printing pages to PDF. A real, printed book is something that we're going to have to keep an eye on as a target as the project evolves. Are we deferring some work? Sure. But I don't think we're creating a big project that wouldn't exist otherwise. > Basic project > monitoring questions need more knowledge of what the system can > produce than I have. I seem to get a bit stuck with the way this is strangely like a wiki, but not a wiki. "PureWikiFans" was definitely the wrong name for me to use, eh? A major reason I suggested TWiki was in response to something you said: "If it goes entirely wiki, we must have good revision control for the maintainers." That's one of TWiki's strengths. If we should be considering something else, we either need concrete proposals, or someone to commit to doing the research to find something. Re the project management questions on the AdminOverview page: > * What is the desired progress of this project? > * How can we measure that? > * What measurements do we expect if everything is running as desired? My feeling is that we can play all of these things by ear. The big point here is what exactly do we have to lose? None of us are betting our life savings on the success of this project. If it stumbles at first, we'll fix it and move on. > * What do we expect to see if one of the alternative > suggested development models is more appropriate? I think we'll know it when we see it. If a great deal of editing or policing proves necessary, for example, the annotation approach might become attractive even to those of us who want to take the "permissive by default" approach to start with. Anton |
From: MJ R. <mj...@ds...> - 2004-04-22 12:45:46
|
On 2004-04-22 07:58:56 +0100 Anton van Straaten <an...@ap...> wrote: > [...] In the absence of that kind of feedback, > we have all been moving forward. If we don't know where the route to reach our destination is, how can we judge whether it is moving forwards instead of moving backwards while arse about face? > I'm perfectly willing to entertain the idea that we're going in a > wrong > direction, but to be convinced of that, I'd need to see alternatives. I know you are capable of better than challenging someone who has described their current lack of time to build or research concrete examples. > I'm > really not sure what you're suggesting we should actually *do*. How about: 1. agree that a published book is our target; 2. find consensus on what the path there should look like (ignoring its construction); 3. implement automated ways to measure whether we are on such a path and moving towards the target; 4. try to facilitate research that schematicians think interesting, if there's time; 5. walk; 6. run? > Regarding output, I'm of the opinion that the cookbook's structure is > likely to evolve even after it goes public. We can revise things later if needed, but not even considering them means that revision will definitely be needed. If you accept that it's cheaper to fix now, then you trade a certain expense later for a little expense now plus a chance of expense later. I guess you see revision as fairly cheap later? > Producing an HTML version > should be fairly straightforward using wget, as Noel suggested. [...] wget is flawed for anything more than a simplistic mirror. > Are we deferring some work? Sure. But I don't think we're creating > a big > project that wouldn't exist otherwise. You are making certain a big project which might be avoided. > My feeling is that we can play all of these things by ear. So you won't discuss them in any sensible way now? > The big point > here is what exactly do we have to lose? The big point is we lose time. Time is precious. Life is short. Man lives for but three score year and ten (or considerably less if chronically ill). If you are determined to filibuster and deny, then I am wasting my time on these emails even. Please be honest and write "no discussion will convince me" rather than asking or inviting questions which you are not interested in. >> * What do we expect to see if one of the alternative >> suggested development models is more appropriate? > I think we'll know it when we see it. You want not to discuss any objective measurement, yet you expect to "see" things like "a great deal of editing or policing"? Unless you just want a free hand to act irrationally, I think you are not making sense. -- MJR/slef My Opinion Only and possibly not of any group I know. Please http://remember.to/edit_messages on lists to be sure I read http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ sl...@ja... Creative copyleft computing services via http://www.ttllp.co.uk/ |
From: Anton v. S. <an...@ap...> - 2004-04-22 20:57:11
|
>> [...] In the absence of that kind of feedback, >> we have all been moving forward. > > If we don't know where the route to reach our destination is, > how can we judge whether it is moving forwards instead of > moving backwards while arse about face? We have a web site which supports easy collaborative, revision controlled, traceable editing, using a simple input format. The resulting pages are directly useable as an online cookbook, have good presentation quality, and can be customized via skins and CSS stylesheets. The output is of sufficient quality that it could conceivably be used directly for book publishing. People are writing recipes using this new setup, with remarkably little fuss, which I consider to be a validation of the approach. Are there still questions to be resolved? Sure. The most important question, of course, is whether the outstanding questions can be resolved without major changes to the current setup. I think they can be. More importantly, alternatives aren't exactly jumping out at us. A "pure wiki" seems like a step backwards in terms of control, and I'm under the impression others agree with that. An annotation-based system would be an option, but I think we have enough flexibility with the current setup to accomodate that, if we need it. >> I'm perfectly willing to entertain the idea that we're going >> in a wrong direction, but to be convinced of that, I'd need >> to see alternatives. > > I know you are capable of better than challenging someone > who has described their current lack of time to build or > research concrete examples. I'm not challenging you. I don't see any fundamental problems with what we're doing at the moment, no-one seems to be advocating any specific alternatives, and none of the ones we've discussed seem to have been ideal. What we do have seems promising to me - not perfect, but workable. So, to be convinced that we're going in the wrong direction, I'd need to see either evidence of some show-stopping problem with the current approach, or specific alternative proposals. If there were promising alternatives, I'd be exploring them, but there's been very little by way of "take a look at package X, I think it can do what we want". FYI, in addition to the various wikibooks etc., I did spend a little time looking at CMS systems, like Postnuke, but I didn't find anything that seemed to offer anything significantly better, and many of them lack basic features we'd need. We could use something like Zope and develop what we need, or work on building up Moshi, but reinventing the most basic functionality we need doesn't seem productive. Ultimately, we're talking about web software, and nothing stops us from plugging in whatever software we need into just about any web-based system. If we wanted to, we could migrate towards a Scheme-based system, which could integrate just fine with what we have now. What we need to start with, though, is an infrastructure which satisfies our basic needs, and is reasonably flexible. I think we have that. I'm open to alternatives, but I'm not planning to expend much more effort looking for them - from what I've seen, I'm not convinced that significantly better alternatives exist as free software. Heck, if there were some commercial package that would do what we need, I'd be willing to chip in money. But I have some experience with document management and authoring systems of various kinds, and I can't think of anything that's really going to help us. >> I'm really not sure what you're suggesting >> we should actually *do*. > > How about: > 1. agree that a published book is our target; I see it as one target. Long before we reach that point, though, I expect the cookbook to be a useful online resource. > 2. find consensus on what the path there should look like > (ignoring its construction); I think our first issue would be to define consensus. However, I think we're a ways from needing to set up something like the Apache Foundation. Perhaps it wouldn't be a bad idea to have an informal voting mechanism, though. > 3. implement automated ways to measure whether we are on > such a path and moving towards the target; What do you have in mind? If you're talking about being able to produce metrics like "new recipes per time period", or "edits per time period", I think that'll be easy enough. I'm not sure that an automated mechanism is really going to tell us the important things, though. > 4. try to facilitate research that schematicians think > interesting, if there's time; Being realistic, there are a handful of us at the moment. One of the best ways to increase our capacity to do useful and interesting things is to increase our numbers. Some of the kinds of things you'd like to do may actually become more practical once we've made the cookbook more public. > 5. walk; > 6. run? Those don't qualify as concrete suggestions. >> Regarding output, I'm of the opinion that the cookbook's >> structure is likely to evolve even after it goes public. > > We can revise things later if needed, but not even considering > them means that revision will definitely be needed. If you accept > that it's cheaper to fix now, then you trade a certain expense > later for a little expense now plus a chance of expense later. > I guess you see revision as fairly cheap later? I see it as something ongoing, an iterative process, and one which we're in the very early stages of. I'm not sure what it is you think we're not considering, that's why I keep asking for specifics. The fact that we haven't actually implemented a response to all the questions that exist at such an early stage of a project like this isn't unusual. >> Producing an HTML version >> should be fairly straightforward using wget, as Noel suggested. [...] > > wget is flawed for anything more than a simplistic mirror. What are we looking for, other than a simplistic mirror? >> Are we deferring some work? Sure. But I don't think we're >> creating a big project that wouldn't exist otherwise. > > You are making certain a big project which might be avoided. I don't agree. I've explained a bit more about my perspective on the book organization in my earlier post. We basically need some way of organizing a bunch of recipes into a structure. I'd like to improve a little on the current setup before going public, and ensure that whatever we do is reasonably automatable, so that it isn't difficult to convert to some other format if that later proves desirable. My suggestion in AdminCookbookViews could provide that ability. >> My feeling is that we can play all of these things by ear. > > So you won't discuss them in any sensible way now? I'm happy to discuss them, but I'm not going to originate discussion on those subjects, because I don't feel the need. You're asking lots of questions, but you're not saying "I think we should do X", where X is something *much* more specific and achievable than "implement automated ways to measure our progress". If you don't provide such input, all we can do is hear your concerns, and decide whether each of us personally feels the need to do anything about them, if there's even anything we *can* do. >> The big point >> here is what exactly do we have to lose? > > The big point is we lose time. Time is precious. Life is short. > Man lives for but three score year and ten (or considerably > less if chronically ill). If you are determined to filibuster > and deny, then I am wasting my time on these emails even. > Please be honest and write "no discussion will convince me" > rather than asking or inviting questions which you are not > interested in. I'm inviting input which we can act on, because that's what's going to make a difference. I'm not in charge of this project, and it doesn't have a voting system afaik. The people who do the work get, in practice, an enormous vote about what work gets done. They make their own decisions about how they spend their time. If you want to influence what they do, you're going to have to do a good job of providing a rationale and recommendations for what they/we should be doing. >>> * What do we expect to see if one of the alternative >>> suggested development models is more appropriate? >> I think we'll know it when we see it. > > You want not to discuss any objective measurement, yet > you expect to "see" things like "a great deal of editing > or policing"? Again, I'm willing to discuss it, but you haven't yet provided much by way of suggestions or proposals to discuss. Just asking leading questions is not enough on its own. We've all heard and noted the questions, and some of us have responded as best we can. If you see problems that you think need to be addressed, but you don't offer some idea of what you see as possible solutions, or what kind of solutions would satisfy you, it's difficult to respond meaningfully. Your 6 points above still don't give us much to go on. > Unless you just want a free hand to act > irrationally, I think you are not making sense. Your perception of what we're doing is certainly very different than mine. For a moment, before you found out that people were actually writing recipes, you seemed to think perhaps the current situation wasn't so "daft". I've explained why I don't see writing recipes now as being problematic. We're still in the process of finalizing some details. Perhaps you'll find things will make more sense once that's been done. Anton |
From: Noel W. <noe...@ya...> - 2004-04-23 11:06:04
|
Hi all, Allow we to had my 2c to this debate. [I havbe a new ergo keyboard that I'm juyst getting used to so please excuse a few typos] MJ Ray writes > How about: > 1. agree that a published book is our target; > 2. find consensus on what the path there should look like (ignoring > its construction); > 3. implement automated ways to measure whether we are on such a path > and moving towards the target; > 4. try to facilitate research that schematicians think interesting, if > there's time; Now I disagree with 1. I believe a published book would be nice, but a working online resource is better than a book if there is tradeoff. (If a book is the goal we should just go straight for a contract.) So at the minimum the system should facilitate an online resource as best as possible and IF we get lucky and end up with enough material to publish, not get in the way of the process of publishing. Ok, so onton the path there. Here I see: 1. We have posited a path (use a wiki) 2. By writing recipes in that wiki we're getting a feel for how it works. The result is that we;ve changd process a few times and are still getting to something that gives the desired result and is easy to use. 3. We;ve taken recommendations from various sources to change features in the wiki. This includes access control and we;re discussing annotation methods. 3. is being discussed on the wiki, under the admin laundry list. 4. I can't comment on. Now I;d love to write more but I'm doing about 10wpm and I have a bus toc catch ;) I'll finish with a reminder to heed the lesson from worse is better. A working, flawed but fixable system is better than a perfevct but never implemented system. Gotta run, Noel ===== Email: noelwelsh <at> yahoo <dot> com Jabber: noelw <at> jabber <dot> org __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash |
From: MJ R. <mj...@ds...> - 2004-04-23 16:34:38
|
On 2004-04-23 12:05:58 +0100 Noel Welsh <noe...@ya...> wrote: > Now I disagree with 1. I believe a published book > would be nice, but a working online resource is better > than a book if there is tradeoff. I think there is always likely to be some tradeoff. So, if there is a working online copy, it does not matter about the book? Previously, you wrote "If PLT Scheme is ever going to attract a significant number of users documentation has to be available in the bookstores programmers visit". I agree with March Noel more than I do with April Noel. > Ok, so onton the path there. Here I see: > 1. We have posited a path (use a wiki) No, "use a wiki" is not a path. "use a wiki" is the construction method of the path. It says nothing about route or schedule. > I'll finish with a > reminder to heed the lesson from worse is better. A > working, flawed but fixable system is better than a > perfevct but never implemented system. ...and a working perfect system is better, albeit impossible. Even followers of "worse is better" usually support use of some metrics so that they can determine improvement. -- MJR/slef My Opinion Only and possibly not of any group I know. Please http://remember.to/edit_messages on lists to be sure I read http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ sl...@ja... Creative copyleft computing services via http://www.ttllp.co.uk/ |
From: Noel W. <noe...@ya...> - 2004-04-27 08:59:02
|
--- MJ Ray <mj...@ds...> wrote: > I think there is always likely to be some tradeoff. > So, if there is a > working online copy, it does not matter about the > book? Not at all. What I meant was that if we had to choose either an online or a published book I'd take the online version. Similarly, when making tradeoffs I'd favour the online version. > Even > followers of "worse is better" usually support use > of some metrics so > that they can determine improvement. What metrics would you suggest here? Noel PS: I hope you make it to the Scheme UK meeting next month so we can discuss this in a higher bandwidth environment. ===== Email: noelwelsh <at> yahoo <dot> com Jabber: noelw <at> jabber <dot> org __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover |
From: MJ R. <mj...@ds...> - 2004-04-23 16:04:19
|
On 2004-04-22 21:57:03 +0100 Anton van Straaten <an...@ap...> wrote: >> I know you are capable of better than challenging someone >> who has described their current lack of time to build or >> research concrete examples. > I'm not challenging you. "Show alternatives" and "I don't see a problem" seem common refrains in this thread, repeating frequently. Reproducing WebIt's formatting didn't seem to produce anything new itself, but it was done anyway. Maybe not all actions need to be individually productive? >> How about: >> 1. agree that a published book is our target; > I see it as one target. Long before we reach that point, though, I > expect > the cookbook to be a useful online resource. There are other sorts of publishing (online) and other benefits than the ultimate target. >> 2. find consensus on what the path there should look like >> (ignoring its construction); > I think our first issue would be to define consensus. [...] http://www.dict.org/ >> 3. implement automated ways to measure whether we are on >> such a path and moving towards the target; > What do you have in mind? We have no answer to 2, so discussing this is premature (and is also why 5 and 6 are ill-defined). >>> Producing an HTML version >>> should be fairly straightforward using wget, as Noel suggested. >>> [...] >> wget is flawed for anything more than a simplistic mirror. > What are we looking for, other than a simplistic mirror? An online book. >>> Are we deferring some work? Sure. But I don't think we're >>> creating a big project that wouldn't exist otherwise. >> You are making certain a big project which might be avoided. > I don't agree. Fine. Enjoy. > I've explained a bit more about my perspective on the book > organization in my earlier post. [...] Is it accurate to paraphrase it as "We'll figure it out some other time"? > You're asking lots of > questions, but you're not saying "I think we should do X", where X is > something *much* more specific and achievable than "implement > automated > ways to measure our progress". I'm asking questions because if no questions are asked, then there is no understanding. I cannot give SMART targets, because there is no definition worth the name yet. There's no point having us all posting "I think we should do X" with no reasoning as to why we should be doing that. There's even less point all doing what we think we should, but that doesn't stop it. "It is clearly visible that something is happening! But are the right things being done? Are they in the right order? You can never be sure until you discover what has been done or what assumptions have been made in error! Then you are faced with rework which takes up much time and effort. "Think of planning as an investment to save time later." -- Trevor Young "To Plan a Project" Kogan Page. Finally, for someone who isn't repeatedly challenging me to build things... > More importantly, alternatives aren't exactly jumping out at us. > no-one seems to be advocating any specific alternatives > I'd need to > see either [...] or specific alternative proposals. > If there were promising alternatives, I'd be exploring them, but > there's > been very little by way of "take a look at package X, I think it can > do > what we want". > I'm not convinced that significantly better > alternatives exist as free software. > I can't think of > anything that's really going to help us. > What do you have in mind? > Those don't qualify as concrete suggestions. > you're not saying "I think we should do X", where X is > something *much* more specific and achievable > If you want to influence what they do, > you're going to have to do a good job of providing a rationale and > recommendations for what they/we should be doing. > you don't offer some idea of what you see as > possible solutions, or what kind of solutions would satisfy you ...you certainly ask for concrete solutions frequently. -- MJR/slef My Opinion Only and possibly not of any group I know. Please http://remember.to/edit_messages on lists to be sure I read http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ sl...@ja... Creative copyleft computing services via http://www.ttllp.co.uk/ |
From: Neil W. V. D. <ne...@ne...> - 2004-04-23 16:17:47
|
Kibbitzing by a recovering methodologist: the Just Do It lifecycle process model seems a good match for this project and contributor makeup. My inbox hath overfloweth with meta-issues! :) |
From: Anton v. S. <an...@ap...> - 2004-04-23 21:21:07
|
MJ Ray wrote: > On 2004-04-22 21:57:03 +0100 Anton van Straaten > <an...@ap...> wrote: > >>> I know you are capable of better than challenging someone >>> who has described their current lack of time to build or >>> research concrete examples. >> I'm not challenging you. > > "Show alternatives" and "I don't see a problem" seem common refrains > in this thread, repeating frequently. Those refrains haven't all been directed at you, and they're challenges only to someone who wants to take them up. Many of the things you quote me as saying just express the way I see the current situation, e.g.: > alternatives aren't exactly jumping out at us. > no-one seems to be advocating any specific alternatives > If there were promising alternatives, I'd be exploring them, but I stand by all of those statements. If you're taking these as me challenging you personally, you're missing my point entirely. In other cases, you've raised points where I have no idea what you have in mind, and I've tried to get clarification on those points. This hasn't just been about suggesting specific solutions, but even when it comes to discussion: you've posed questions without offering an opinion on those yourself (other than a sort of implicit one), and without giving much to go on as to what you have in mind. I'm finding it difficult to respond to those questions. When I responded to some of them with "we can play that by ear", you feel I'm stonewalling discussion. I'd love to have a *discussion*, in which we exchange opinions and perspective on some of these matters. I don't feel that this is what's been happening on many of these points. >>> How about: >>> 1. agree that a published book is our target; >> I see it as one target. Long before we reach that point, though, I >> expect the cookbook to be a useful online resource. > > There are other sorts of publishing (online) and other benefits than > the ultimate target. I think we agree that an online resource and hopefully ultimately a published book is our target. I'm not sure when you say "published book" and "publishing (online)" whether you have something more in mind than what we're currently working towards. >>> 2. find consensus on what the path there should look like >>> (ignoring its construction); >> I think our first issue would be to define consensus. [...] > > http://www.dict.org/ I like the m-w.com definition, "the judgment arrived at by most of those concerned". >>>> Producing an HTML version >>>> should be fairly straightforward using wget, as Noel suggested. >>>> [...] >>> wget is flawed for anything more than a simplistic mirror. >> What are we looking for, other than a simplistic mirror? > > An online book. OK. What is it about what you consider to be an online book, that would not be addressed by the kind of site layout we're currently working towards? Is there some way in which a simplistic mirror of such a site would not meet the requirements for an online book? From my perspective, the Twiki site will make an acceptable online book. We may want some features like having next page/previous page links, and I don't think we'll necessarily have that at the outset, but it's certainly achievable. Ordinary mirroring should work fine for a site like that. >> I've explained a bit more about my perspective on the book >> organization in my earlier post. [...] > > Is it accurate to paraphrase it as "We'll figure it out some > other time"? No, not at all. We're figuring it out right now, and anyone is welcome to get involved to whatever extent they wish. My goal, as described in the AdminCookbookViews topic, is to come up with a better solution for organizing the recipes and producing what I'm calling index pages, without requiring contributors to have to make changes in multiple places to add new recipes. I think that with this issue resolved, we will have something that can support contributions from a larger group. I'm not looking to make this organization mechanism into a big project. I think it can be kept small, simple, and focused on producing what the cookbook needs. If it turns out to require too much work to be done in the near future, then I think we could get away with something like the current approach, using the Twiki %TOC% tag to build index pages. However, I see some disadvantages to that, which could turn into management problems. The general problem I'd like to avoid is having index pages be free-format wiki text, since that makes it more difficult to organize the book, and produce more than one view of it. The aspect of this which falls into the category of "we'll figure it out some other time" are things which become necessary as the project develops - responding and adapting to needs which become apparent. Although we can anticipate some of those, we can't necessarily correctly anticipate their relative importance. Overplanning and underplanning can be equally time-wasting. We need to strike a balance, which will be determined in part by the resources we have available, which also means that it's likely that many compromises will have to be made. > I'm asking questions because if no questions are asked, then there is > no understanding. I cannot give SMART targets, because there is no > definition worth the name yet. There's no point having us all posting > "I think we should do X" with no reasoning as to why we should be > doing that. Great, please feel free to give your reasoning, too. I've been trying to do that as best I can, myself. > There's even less point all doing what we think we should, > but that doesn't stop it. I disagree on that. There've been a bunch of good recipes written, with very little coordination or discussion. I don't see a problem with that. As I've said, I think we can support those recipes in future iterations of the cookbook, even if we change formats. I'm willing to work to make sure that happens, although I don't think much work will be involved. > "It is clearly visible that something is happening! But are the > right things being done? Are they in the right order? You can never be > sure until you discover what has been done or what assumptions have > been made in error! Then you are faced with rework which takes up much > time and effort. > "Think of planning as an investment to save time later." -- Trevor > Young "To Plan a Project" Kogan Page. Right. Having led some significant software projects, I think I have a reasonable handle on such things. However, part of what we're dealing with here is that we can't verify all our assumptions up front, and we can't be sure that we're doing the right things. A lot depends on what the tools we have available are capable of, and also on what happens after we announce the site. A common way to deal with these kind of unknowns in real-life projects, software or otherwise, is to start with a small solution and iteratively refine it until the desired goal is reached. It's often happens that the final achieved goal is somewhat different from the way it was initially conceived, usually for reasons that would have been difficult to predict. Developing and refining an initial solution helps even the developers to determine what is and isn't important. In the end, it may turn out that the line between "prototype" and "final product" is nonexistent. OTOH, the first prototype might need to be thrown away. You may see that as wasted work, but the reality is that in many cases, there are few good alternatives, because development of the prototype is essentially development of the requirements and specifications. There's feedback between what's wanted - that vague idea in our heads - and what we can actually produce with the resources available. This relates directly to one of your action points: >>> 2. find consensus on what the path there should look like >>> (ignoring its construction); I think the construction and the path are intertwined. The features and limits of the tools we use to do the construction will affect the path. > Finally, for someone who isn't repeatedly challenging me to build > things... I've snipped all my quoted comments which were not directed specifically at you, and will respond to the remaining ones. >> What do you have in mind? I didn't have a clue what you were thinking of, and so I asked for an explanation. Without that, I can't respond meaningfully. However, I made an attempt anyway - here's the original exchange: >> 3. implement automated ways to measure whether we are on >> such a path and moving towards the target; > > What do you have in mind? If you're talking about being able to > produce metrics like "new recipes per time period", or "edits > per time period", I think that'll be easy enough. I'm not sure > that an automated mechanism is really going to tell us the > important things, though. I'm doing my best to respond to the points you're raising. Next: >> Those don't qualify as concrete suggestions. This was in response to your points "5. walk; 6. run?". I considered that unconstructive. My remaining comments were indeed directed at you: >> you're not saying "I think we should do X", where X is >> something *much* more specific and achievable ... >> If you want to influence what they do, >> you're going to have to do a good job of providing a rationale >> and recommendations for what they/we should be doing. ... >> you don't offer some idea of what you see as >> possible solutions, or what kind of solutions would satisfy you > > ...you certainly ask for concrete solutions frequently. I'm mainly asking for some detail on what you have in mind on many of these issues, because it just isn't clear to me. So far, I've gathered that you think we should halt activity until we've agreed on the "path [to] a published book". Once again, I'm not sure how to respond to this - I need to know more about what you have in mind. Otherwise, any response I give is likely to met with the sort of response which you gave Noel: > No, "use a wiki" is not a path. "use a wiki" is the construction > method of the path. It says nothing about route or schedule. I don't want to play guessing games. Anton |
From: MJ R. <mj...@ds...> - 2004-04-24 12:35:25
|
On 2004-04-23 22:21:04 +0100 Anton van Straaten <an...@ap...> wrote: > I stand by all of those statements. If you're taking these as me > challenging you personally, you're missing my point entirely. If I remove the challenges to build/show concrete examples, then there isn't much in most of your replies. > you've posed questions without offering an opinion on those > yourself (other than a sort of implicit one), and without giving much > to > go on as to what you have in mind. Sometimes this is because I have an open mind as to how the problem is best solved. Prejudicing a discussion doesn't seem helpful. > I'm finding it difficult to respond to those questions. When I > responded > to some of them with "we can play that by ear", you feel I'm > stonewalling > discussion. Yes, it's along the lines of "How should we solve this? What is the aim here?" being answered by "We can solve it later." It doesn't actually answer the questions at all and barely relates to them. >> An online book. > OK. What is it about what you consider to be an online book, that > would > not be addressed by the kind of site layout we're currently working > towards? Hard to say, as I have little grasp of the "kind of site layout we're currently working towards". > Is there some way in which a simplistic mirror of such a site > would not meet the requirements for an online book? wget doesn't even gather all page objects. For example, @import-ed CSS files get missed IIRC. > I'm not looking to make this organization mechanism into a big > project. I > think it can be kept small, simple, and focused on producing what the > cookbook needs. There seems little interest in discussing what the cookbook needs. Appealing to being focused on it seems groundless. >> I'm asking questions because if no questions are asked, then there is >> no understanding. I cannot give SMART targets, because there is no >> definition worth the name yet. There's no point having us all posting >> "I think we should do X" with no reasoning as to why we should be >> doing that. > Great, please feel free to give your reasoning, too. I've been > trying to > do that as best I can, myself. The bug is the lack of definition! Without that, there can be no rational reasoning. Trying to explore this definition is where we came in. > Right. Having led some significant software projects, I think I have > a > reasonable handle on such things. However, part of what we're dealing > with here is that we can't verify all our assumptions up front, and we > can't be sure that we're doing the right things. [...] We could record what assumptions we are making and figure out how we might verify them. > the first prototype might need to be thrown away. We already seem to have done that. How many will be thrown away before we actually try to learn from the discarded? > I think the construction and the path are intertwined. The features > and > limits of the tools we use to do the construction will affect the > path. Indeed. The construction mustn't be allowed to limit analysis of the path, even if it limits the path. That analysis may suggest improvements to the construction. > So far, I've gathered that you think we should halt activity until > we've > agreed on the "path [to] a published book". What? Searching my sent email for this view doesn't find it. Are you inventing opinions for me? I think you should address the basic questions early on, not all stop until there is a Grand Plan. This is probably my last batch of email on this topic for a while, because I am away at conference next week and there are more useful things to do this weekend. Good luck, but I think it needs more than that. -- MJR/slef My Opinion Only and possibly not of any group I know. Please http://remember.to/edit_messages on lists to be sure I read http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ sl...@ja... Creative copyleft computing services via http://www.ttllp.co.uk/ |
From: Anton v. S. <an...@ap...> - 2004-04-26 08:02:08
|
MJ Ray wrote: > Hard to say, as I have little grasp of the "kind of site layout > we're currently working towards". I'm sorry about that. I think having a discussion in which we agree explicitly on goals, vision, requirements, plan etc. would be useful. However, it all takes time; writing it up takes time. I welcome any constructive input along these lines. However, a number of us already seemed to have a substantial amount of implicit agreement or common vision, which can be an enormous saver of time. Of course, that can break down if there are people who don't share that implicit agreement. > This is probably my last batch of email on this topic for a while, > because I am away at conference next week and there are more useful > things to do this weekend. Good luck, but I think it needs more than > that. I think we have a lot more than luck going for us. Perhaps by the time you have another chance to look at this, some of what you've been asking about will be more evident. You might not agree with the process that's been used so far, but I think you might find that it has a good end result. Anton |