From: Anton v. S. <an...@ap...> - 2004-04-07 18:55:25
|
MJ Ray wrote: > On 2004-04-05 19:37:46 +0100 Anton van Straaten > <an...@ap...> wrote: > > > That's a good point. But won't this mean that it becomes up to the > > editors to integrate new material, so instead of working to "police" > > contributions that don't fit, some work will have to be done for > > many or most contributions, even good ones, to make the cookbook > > hold together rather than be a ragtag collection of random > > contributions? > > Probably, but someone needs to tend a pure wiki to do that anyway. > If this is a wiki with "schematics" on it, they ought to become a > schematician if they will do much editing, surely? If they will be doing much editing, I think it would be helpful if they create an account so they're identifiable and accountable in the revision control. What other requirements should there be to be a schematician? > > I've seen sites with such random collections, and they're not that > > useful because there may be ten solutions to a given problem, and > > most or all of them might suck. Someone has to do editing work to > > correct that. If the original contributors are responsible and > > sensible, they can do at least some of that work. > > I think you missed "with sufficient time" from the list of > requirements for contributors. The kind of thing I was thinking of is this: when adding a new recipe or other topic, contributors will need to find a chapter or section to include it in (or it'll just float undiscovered until someone does that). In that process, they may notice if there's other material which duplicates what they're trying to add. This potentially avoids the problem of ten people submitting solutions to the same problem, and makes it more likely that existing solutions will be enhanced. > Regardless, wiki-ness doesn't prevent "someone has to do editing work > to correct that" if you get ten partial solutions. Wiki-ness also > introduces the possibility that the non-sucky solutions will be edited > to suck and someone has to edit them again, too. True. > > It comes down to how much you trust the contributors. [...] > > I disagree. I think I do not distrust the contributors more than you. Perhaps the correct word is optimism, as opposed to trust. I suspect that we won't have to worry a lot about non-sucky solutions being edited to suck. Legitimate contributors are likely to recognize good material, and be reluctant to mess with them. If that does become a problem, it would be possible to institute additional controls. Twiki does support per-topic access control, so it would be possible to do something like "bless" a topic as having reached a state of non-suckiness, make it only editable by selected editors, and require that any additions or annotations be made on a separate topic (which could be included in the original topic). But my feeling is this should only be a fallback plan in the event of problems, or something we consider when we have more experience with the book, and when there is more content to protect. Otherwise, it just seems as though we're putting up barriers in the way of people making effective contributions. > Rather, I believe the pure wiki is requiring more effort from both > contributors and editors than an annotation-based system. > The requirement was to make this thing easier and I don't think a pure > wiki solution will. My experience with other open project wikis (the > local LUG, Oekonux, GNUstep, Koha, Gobo, amongst others) suggests they > require active maintenance and will be subject to attacks. To me, this seems like another argument for some minimal access control. > Even if all > contributors are friendly, there will be script-based attacks on it. > Please consider this experience even if you don't agree with my > interpretation if the time demands. As always with security, there are conflicting requirements here. To mitigate attacks, access control is needed at some level. Two contrasting approaches we've discussed are: a restricted list of authorized editors who can edit the main content, plus unrestricted ability to submit annotations or similar; vs. requiring all contributors to log in in order to make changes, but allowing them to edit anything. As I mentioned above, some intermediate approaches are possible, e.g. the latter model with some pages being more restricted than others. Any model that supports completely anonymous contributions is going to have more of a problem with attacks and other abuse. That even applies to the "protected content + anonymous annotations" model; it's just that in that case, the protected content isn't compromised by abuse. Work will still be needed to deal with abusive contributions. My personal feeling is that I'm more concerned about allowing any anonymous updates, than I am about legitimate contributors screwing things up. I just want to make clear: I don't care whether we use a wiki, or whether it's TWiki. AFAIR, other than Moshi which doesn't yet have everything we need, nothing else specific has been proposed. I'm trying to facilitate getting this done, because I'm interested in the goals of the project, and I happened to have something set up that seemed like a pretty good match for what Noel described in his "Future of the Cookbook" message. Having proposed TWiki and provided an installation of it, I feel a responsibility to help make it work. BTW, regarding Wiki-based books, Noel originally gave this example: http://wikibooks.org/wiki/Main_Page , to add to the list. > I don't understand the plan for making stable releases of a pure-wiki > cookbook. Are we deferring work for later? Do you mean the printed version? For online purposes, making a stable release could be as simple as a snapshot of the pages at the point we're interested in. For printing, we don't yet have a solution for automatically generating a complete table of contents from a hierarchical collection of topics. However, I'm looking at the TocPlugin for that purpose right now. As the Python Cookbook example indicates, a printed book is likely to require some manual filtering and formatting anyway. Anton |
From: MJ R. <mj...@ds...> - 2004-04-08 17:23:21
|
On 2004-04-07 19:55:46 +0100 Anton van Straaten <an...@ap...> wrote: > [...] This potentially avoids the problem of ten people > submitting solutions to the same problem, and makes it more likely > that > existing solutions will be enhanced. I don't see a significant difference between PureWiki and annotation-based in this respect. People will get it wrong sometimes, both ways. > [...] But my feeling is this should only be a fallback plan in > the event of problems, or something we consider when we have more > experience > with the book, and when there is more content to protect. Otherwise, > it > just seems as though we're putting up barriers in the way of people > making > effective contributions. I think we should plan to deal with this likely case before it happens. We always put up barriers. We need to choose which ones. >> [...] My experience with other open project wikis (the >> local LUG, Oekonux, GNUstep, Koha, Gobo, amongst others) suggests >> they >> require active maintenance and will be subject to attacks. > To me, this seems like another argument for some minimal access > control. I agree with you that it's a compromise. However, access controls do not prevent attacks. Any control sufficient to deter attacks will also deter contribution. Ultimately, you cannot prevent all attacks. Maintenance is unavoidable. > Any model that supports completely anonymous contributions is going > to have > more of a problem with attacks and other abuse. That even applies to > the > "protected content + anonymous annotations" model; it's just that in > that > case, the protected content isn't compromised by abuse. Work will > still be > needed to deal with abusive contributions. Sure, work is unavoidable. To me, ticking a list of contributions for junking seems easier than figuring out how to drive the revision controls or editing out inserted rubbish. > I just want to make clear: I don't care whether we use a wiki, or > whether > it's TWiki. AFAIR, other than Moshi which doesn't yet have > everything we > need, nothing else specific has been proposed. [...] I want to understand what is needed a bit more before rushing in and implementing. We're already throwing one away, after all. > BTW, regarding Wiki-based books, Noel originally gave this example: > http://wikibooks.org/wiki/Main_Page , to add to the list. Most of the developed books there appear to have only a small number of authors (typically 1 or 2), or have been imported from external non-wiki developments. >> I don't understand the plan for making stable releases of a pure-wiki >> cookbook. Are we deferring work for later? > Do you mean the printed version? Whatever we choose to release as. Printed versions have been mentioned. Tarballs/packages seem another obvious one. > For online purposes, making a stable > release could be as simple as a snapshot of the pages at the point > we're > interested in. [...] Would this have dead links to wiki controls? > As the Python Cookbook example indicates, a printed book is likely to > require some manual filtering and formatting anyway. We should learn from their mistakes. I am sure many books are released with less pain than their description, which suggests that the PureWiki defers a lot of work. We could end up with a fine development edition and no way to cut reasonable releases. I think that depresses projects. -- 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-08 21:53:35
|
MJ Ray wrote: > I want to understand what is needed a bit more before rushing in and > implementing. We're already throwing one away, after all. I'm all in favor of that. However, I'd like to point out that the one being thrown away has already been converted to the new format, and it didn't take very long - maybe an hour or so for the orginal conversion, taking into account experimentation with the appropriate formats. I think something similar is true of the TWiki version: we're dealing with fairly simple markup formats, and at worst, some scripts can deal with them easily enough. Also, we're not talking about putting up something mission critical - I think we have room to evolve in response to what actually happens, rather than trying to cater up front for all potential problems. But I agree that a decent amount of up-front planning is a good idea. I'll respond on more of the specifics tomorrow. Noel wrote: > Mr Noel H. Welsh > Head of Corporate Junkets > The Scheme Foundation, Inc I'd like to offer my services as head of the Caribbean division. Naturally, for image purposes, we'll need beachfront regional headquarters... Anton |
From: Noel W. <noe...@ya...> - 2004-04-13 15:10:16
|
Hi all, Some thoughts: Annotations vs Free Edits ------------------------- My preference is for wiki-esque free edits vs privileged immutable recipes and annotations. Why? It allows recipes to be iteratively refined to perfection, versus the reader reading and integrating all the comments to obtain the final version (A small example in the Python cookbook is http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/194373) This makes several assumptions about the community: potential editors, like me, are lazy and won't do much work :-) and the contributors will be of high quality so iterative revision will improve not decrease quality. Access Control -------------- I'm agreed some sort of access control is needed. Manual spamming can be effectively fought with any decent system. Automatic spamming must be made too difficult to be worthwhile. I suggest: - only signed up users can contribute - signing up requires typing in a phrase/number displayed in a non-machine readable graphic (ala Slashdot) OR email verification. I personally prefer the phrase/number idea as it gets people contributing faster - some sort of flow control to stop robots hammering the site (e.g. edits only allowed every 20 seconds) Generating Releases ------------------- There are two issues here: 1. Generating tarballs for local installs 2. Generating text for a printed document I think 1. can be addressed with wget and some link munging. Addressing 2...I can only think of two things that might help: make certain recipes unchangeable when they reach a high enough standard and force all recipes to explicitly annotate code. Noel ===== Email: noelwelsh <at> yahoo <dot> com Jabber: noelw <at> jabber <dot> org __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ |
From: Anton v. S. <an...@ap...> - 2004-04-14 09:14:56
|
Noel Welsh wrote: > Annotations vs Free Edits > ------------------------- > > My preference is for wiki-esque free edits vs > privileged immutable recipes and annotations. Why? > It allows recipes to be iteratively refined to > perfection, > versus the reader reading and integrating all the > comments to obtain the final version (A small example > in the Python cookbook is > > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/194373) > > This makes several assumptions about the community: > potential editors, like me, are lazy and won't do much > work :-) and the contributors will be of high quality > so iterative revision will improve not decrease > quality. I'm in complete agreement with all of this (up to and including being lazy...) > Access Control > -------------- > > I'm agreed some sort of access control is needed. > Manual spamming can be effectively fought with any > decent system. Automatic spamming must be made too > difficult to be worthwhile. I suggest: > > - only signed up users can contribute > > - signing up requires typing in a phrase/number > displayed in a non-machine readable graphic (ala > Slashdot) OR email verification. I personally prefer > the phrase/number idea as it gets people contributing > faster > > - some sort of flow control to stop robots hammering > the site (e.g. edits only allowed every 20 seconds) I agree with all of this in principle. Initially, I'd suggest we could just stick to ordinary signup with email confirmation, with the goal being to go for the additional security measures as time or necessity permits/requires. > Generating Releases > ------------------- > > There are two issues here: > > 1. Generating tarballs for local installs > 2. Generating text for a printed document > > I think 1. can be addressed with wget and some link > munging. wget was my thought also. > Addressing 2...I can only think of two > things that might help: make certain recipes unchangeable > when they reach a high enough standard and force all > recipes to explicitly annotate code. I think #2 will involve some ongoing policing, not just editing pages but making sure we have standards for layout, and that people know about them. (Maybe some kind of script to check for known problems could help.) I don't think we've really worked out enough of the layout standards yet, but I think some of it will have to evolve as content is added. Anton |
From: MJ R. <mj...@ds...> - 2004-04-14 10:07:59
|
On 2004-04-13 16:10:09 +0100 Noel Welsh <noe...@ya...> wrote: > My preference is for wiki-esque free edits vs > privileged immutable recipes and annotations. Why? It > allows recipes to be iteratively refined to > perfection, It also means you will never stabilise at the best possible recipe. If we really have an active community, it seems similar to a simplistic Genetic Algorithm approach to cookbook authorship. > versus the reader reading and integrating all the > comments to obtain the final version (A small example > in the Python cookbook is > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/194373) Why do people keep referring to that one? It seems to be a polar opposite that has more severe editor qualification than anyone has suggested here. Please stop it. Even I think we should have a more open editor approach than that. I could equally well refer to http://c2.com/cgi/wiki as an example of why a wiki can't produce a good cookbook, but I don't. It's just not relevant to this discussion. > This makes several assumptions about the community: > potential editors, like me, are lazy and won't do much > work :-) and the contributors will be of high quality > so iterative revision will improve not decrease > quality. Non-working editors will hinder the book in either model. I don't think that is a valid argument either way. Have we any data to favour the assumption of "iterative revision will improve not decrease quality" over "some contributors will goof sometimes"? People edit trivially-checkable correct information in wikipedia to incorrect. > - some sort of flow control to stop robots hammering > the site (e.g. edits only allowed every 20 seconds) That needs to be a bit more sophisticated, else quick typo fixes get rejected, which is really annoying. Maybe "max 3 edits a minute from an IP" but some spam-robots trickle edits to try to avoid being spotted in logfiles on busy wikis now. -- 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-14 16:42:41
|
> > My preference is for wiki-esque free edits vs > > privileged immutable recipes and annotations. Why? It > > allows recipes to be iteratively refined to > > perfection, > > It also means you will never stabilise at the best possible recipe. If > we really have an active community, it seems similar to a simplistic > Genetic Algorithm approach to cookbook authorship. We'll always have the option of selectively freezing pages, which Noel mentioned, and I think we'll probably reach a point where we want to use that. That relates to this question: > Have we any data to favour the assumption of "iterative revision > will improve not decrease quality" over "some contributors will > goof sometimes"? People edit trivially-checkable correct > information in wikipedia to incorrect. No, we don't have any data. However, I think we could easily collect some, by starting out as open as possible. We don't currently have a lot of content to protect, and if we don't try, we'll never know what the Scheme community is capable of here. > Non-working editors will hinder the book in either model. > I don't think that is a valid argument either way. The argument as I see it is that at least some of our contributors are likely to be responsible, and save the editors some work, as opposed to knowing for sure that every contribution has to be edited to integrate it. The question is whether other, less ideal contributors will completely offset this, or not. I think this can partially be addressed by having some guidelines about editing existing content. > > - some sort of flow control to stop robots hammering > > the site (e.g. edits only allowed every 20 seconds) > > That needs to be a bit more sophisticated, else quick typo fixes get > rejected, which is really annoying. Maybe "max 3 edits a minute from > an IP" but some spam-robots trickle edits to try to avoid being > spotted in logfiles on busy wikis now. I'll give this some thought, and check what other twikis have done. However, I'm not convinced that bots signing up for accounts are going to be a big problem at first, based on reports from other twiki sites, and also that we're not going to be a very high-profile wiki (at least until the cookbook starts competing with J2EE and we're indundated with millions of desperate Java and C# developers...) Seriously, in this area too, I believe we can try it out and see how it goes, and evolve our defenses over time. Here's a semi-tongue-in-cheek idea, which solves both the bot problem and the poor contributor problem in a single stroke of genius: to sign up, ask contributors to answer a tricky question about Scheme or a small Scheme program. If they fail, give them simpler questions until they pass. Assign them full edit vs. annotation privileges based on how well they do. Assessing spelling capability might also be a thought... ;) Anton |
From: MJ R. <mj...@ds...> - 2004-04-14 18:01:59
|
On 2004-04-14 17:42:54 +0100 Anton van Straaten <an...@ap...> wrote: > We'll always have the option of selectively freezing pages, which Noel > mentioned, and I think we'll probably reach a point where we want to > use > that. I still favour page-including-annotations as a "middle way" to avoid using both these extremes (open zoo and totally frozen). >> Have we any data to favour the assumption of "iterative revision >> will improve not decrease quality" over "some contributors will >> goof sometimes"? [...] > No, we don't have any data. However, I think we could easily collect > some, > by starting out as open as possible. OK, sounds like an interesting research. What's the data collection plan? How do we judge quality? Ask people to "rate this page" and see how it changes over time? Are there other measures we could use? > The argument as I see it is that at least some of our contributors are > likely to be responsible, and save the editors some work, as opposed > to > knowing for sure that every contribution has to be edited to > integrate it. Not really. I think we can safely assume that every page will need some editing. If the editor has some control over how new changes are integrated, then the editing can be split up into small pieces over a long time. If it's totally unrestricted, then there will need to be more drastic detangling at regular intervals, unless a large proportion of our contributors are good editors (which seems unlikely, to be honest... even gifted authors have editors). > The question is whether other, less ideal contributors will completely > offset this, or not. I think this can partially be addressed by > having some > guidelines about editing existing content. That would surely help. A lot of things are going by on the list and I don't know which are still relevant. -- 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-19 16:00:51
|
--- Anton van Straaten <an...@ap...> wrote: > No, we don't have any data. However, I think we > could easily collect some, by starting out as open as > possible. We don't currently have a lot of > content to protect, and if we don't try, we'll never > know what the Scheme community is capable of here. I'm happy with this. I believe our discussion has highlighted a difference of philosophy. Myself and Anton seem to prefer adaptation, MJ preplanning (coarsely put). I don't think either is better but they are certainly contradictory and I can't see a resolution that doesn't end up being a compromise no-one is happy with. The cookbook is chugging along quite nicely as is. In a few more days Jens will probably complete all the recipes ;-) I'll concentrate on fixing up the Author Guide and Table of Contents. 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-19 17:04:58
|
On 2004-04-19 17:00:37 +0100 Noel Welsh <noe...@ya...> wrote: > I'm happy with this. I believe our discussion has > highlighted a difference of philosophy. Myself and > Anton seem to prefer adaptation, MJ preplanning > (coarsely put). To reference my home town's profession: Cobblers. Your description of me is inaccurate and I think describing "ignore fundamental questions" as "prefer adaptation" is too ;-) My lack of time is because I prefer doing to long email arguments, like my running around near Olympia tomorrow. I'll have more fun than previous expos, and any of you in the area, please email or phone me if you want to meet up. I wish I had time to work on this now, but I don't have time to build an annotation-based edition and the developers of the purewiki cookbook have not documented it. The cookbook pages at schematics.sf.net makes no reference to the wiki edition; once you find schematics.webhop.net, the author guide is apparently incomplete on key topics like creating recipes and editing existing ones; and the mailing list has contradictory messages about what is going on. Yourself and Anton seem to prefer to just present us with done deals in your favour rather than even try to look at the questions (or maybe I am missing some emails since last week's troubles here... hard to tell, as sourceforge seems broken, yet again). -- 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: <jen...@so...> - 2004-04-19 17:36:45
|
MJ Ray wrote: > To reference my home town's profession: Cobblers. Your description of m= e=20 > is inaccurate and I think describing "ignore fundamental questions" as=20 > "prefer adaptation" is too ;-) My lack of time is because I prefer doin= g=20 > to long email arguments, like my running around near Olympia tomorrow.=20 Sounds fun. > I'll have more fun than previous expos, and any of you in the area,=20 > please email or phone me if you want to meet up. > I wish I had time to work on this now, but I don't have time to build a= n=20 > annotation-based edition and the developers of the purewiki cookbook=20 > have not documented it.=20 This confuses me. > The cookbook pages at schematics.sf.net makes no=20 > reference to the wiki edition; once you find schematics.webhop.net, the= =20 > author guide is apparently incomplete on key topics like creating=20 > recipes and editing existing ones; and the mailing list has=20 > contradictory messages about what is going on. Hey - we have started yet. I have a feeling that you all are taking the sorrows ahead of time. It'll be a long while before there are enough to even considering publishing anything. And now - the real reason for this reply. <http://wikibooks.org/wiki/Cookbook> --=20 Jens Axel S=F8gaard |
From: Noel W. <noe...@ya...> - 2004-04-20 13:59:33
|
--- Jens_Axel_Søgaard <jen...@so...> wrote: > > And now - the real reason for this reply. > > <http://wikibooks.org/wiki/Cookbook> Is Scheme a cuisine, technique or special diet? N. ===== 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-22 16:36:10
|
On 2004-04-19 18:35:00 +0100 Jens Axel S=C3=B8gaard <jensaxel@soegaard.n= et> wrote: > MJ Ray wrote: >> I wish I had time to work on this now, but I don't have time to build= an=20 >> annotation-based edition and the developers of the purewiki cookbook = have=20 >> not documented it. > This confuses me. My lack of time is not confusing. The lack of documentation confused me = too. > I have a feeling that you all are taking the sorrows ahead of time. > It'll be a long while before there are enough to even considering > publishing anything. It looks like it'll be longer than that. --=20 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-20 06:25:35
|
MJ Ray wrote: > To reference my home town's profession: Cobblers. Your description of > me is inaccurate and I think describing "ignore fundamental questions" > as "prefer adaptation" is too ;-) I don't want to ignore any fundamental questions. Then again, this is not a commercial product launch. Even commercial products grow and change over time, and are never perfect in their first incarnation. This is also not a project with a potential contributor base or readership on the scale of a Wikipedia or most of the others we've talked about. I've started a page listing some of the infrastructure items we've discussed so far, at: http://shizuku.appsolutions.com/twiki/bin/view/Cookbook/AdminOverview As always, feel free to pitch in and add/edit etc. I'll be adding my own thoughts on how & when any of these issues should be dealt with. In general, my feeling is that many of these things can be dealt with as they arise ("adaptation"), as long as we have some idea and agreement about how we plan to deal with the potentially more important ones, should they arise. The two categories of issue that I see as exceptions to this are anything that negatively affects the ease of use of the cookbook, for contributors; and anything that could necessitate major restructuring in future that we can avoid with some planning up front. Re the broader question of approach, and trying to avoid judgemental terms, I think it can't be denied that we're talking about with much of this stuff is taking risks. I think Noel and I are willing to take some calculated risks in the *hope* that they will pay off, for example in allowing pages to be edited by anyone with an account. Our hope that it will pay off could be unfounded, but I think we both feel we'd be better off if it does. If it doesn't, then no worries, we can change the approach - we don't have much to lose at this stage. Still, I agree we should have at least some contingency plans for alternative approaches, and the above page is a start in that direction. If we discuss some of those plans now, we'll be able to implement them that much faster, later. > My lack of time is because I prefer > doing to long email arguments, like my running around near Olympia > tomorrow. I'll have more fun than previous expos, and any of you in > the area, please email or phone me if you want to meet up. I think I'm on the wrong side of an ocean, but have fun! Re "prefering doing", if there's something stopping you from doing anything on the current system, please let me know. > I wish I had time to work on this now, but I don't have time to build > an annotation-based edition and the developers of the purewiki > cookbook have not documented it. Right - time is a basic limit on what we all can do. More documentation will follow. In the meantime, you can look at the new Cookbook topics being written all the time, to see the structure being used; or ask questions. The recommended approach is mostly documented on the AuthorGuide page. There's not a "How to Use Twiki" for authors yet, but the entire TWiki docs are there for the browsing. Re annotations, I've added a topic called AdminAnnotationProposal which describes a way we could integrate annotations with the current cookbook design, if we want to. But again, unless we collectively decide that we need to start out with an annotation capability, I don't think that setting up such a system has to be done up front. If someone wants to tackle it, great. Otherwise, if we find we really need annotations, then in a worst-case scenario we can temporarily block edits on some or all pages until an annotation capability is set up. > The cookbook pages at > schematics.sf.net makes no reference to the wiki edition; once you > find schematics.webhop.net, the author guide is apparently incomplete > on key topics like creating recipes and editing existing ones; and the > mailing list has contradictory messages about what is going on. None of this is targeted at anyone other than those of us setting up the system, at this point. Everyone is free to contribute ideas, time, fix things that are broken, ask questions, whatever. If I can help anyone with anything, please just ask. A big part of the reason that the author guide documentation is incomplete is that there are still some unresolved issues. I spent quite a bit of time looking at different ways to structure the cookbook - more time, in fact, dealing with table of contents and multi-level inclusion issues than I did on any other single aspect of the cookbook. What we have right now is workable, but not really "scalable" to things like the easy production of a printed book, IMO. My latest idea on this subject is in the topic AdminCookbookViews. I'm assuming we'll take care of all of the above issues, to some reasonable degree, before unleashing the cookbook on the world - there wouldn't be much point in doing otherwise. > Yourself and Anton seem to prefer to just present us with done deals > in your favour rather than even try to look at the questions (or maybe > I am missing some emails since last week's troubles here... hard to > tell, as sourceforge seems broken, yet again). It is not my intention to "present done deals in [my] favour". With this kind of stuff, it's often a lot easier to show than to describe. For example, I could have spent a long time writing out explanations of how a Twiki cookbook might work, but with a few hours work I was able to demonstrate it. If there had been a collective "ugh" in response, that wouldn't bother me, and we'd carry on looking for better alternatives. The same goes for everything else that has happened on the site since then. Using a proof of concept to communicate and possibly help move things forward shouldn't be construed as "presenting a done deal". In my experience, in distributed collaborative work, especially volunteer work where people are working on what interests them or what they feel needs to be done, there's a lot of that kind of thing. Contributions are not "done deals" that can't be objected to or changed, they become part of a collective resource that we all contribute to, and can change on an ongoing basis. In this case, that applies nearly as much to the cookbook's infrastructure as it does to the cookbook content. The same thing goes for everything I've written on the site, and my proposals for structuring the cookbook. If someone has different ideas about how to structure the cookbook, by all means go and change or annotate the AuthorGuide, the new AdminOverview topic, or create new topics to propose other things. That's kind of the point of this stuff. Think of every contribution as a request for feedback, or for more contributions. Anton |
From: MJ R. <mj...@ds...> - 2004-04-21 23:59:33
|
On 2004-04-20 07:26:13 +0100 Anton van Straaten <an...@ap...> wrote: > I've started a page listing some of the infrastructure items we've > discussed > so far, at: > http://shizuku.appsolutions.com/twiki/bin/view/Cookbook/AdminOverview Now I don't know which Cookbook wiki I am supposed to be using: is this the one at webhop too? > There's not a "How to Use Twiki" for authors yet, but the entire > TWiki docs > are there for the browsing. This is quite a problem. I have been using wikis since the c2.com one, but I do not know TWiki and it does not seem very wiki-like, with new obfuscating jargon (topics?) and markup. Aren't wikis meant to be simple? Needing to learn Twiki seems another barrier to entry. > Re annotations, I've added a topic called AdminAnnotationProposal > which > describes a way we could integrate annotations with the current > cookbook > design, if we want to. It sounds very complicated and lots of perl hacking. If you are confident of being able to do it, I'll take your word for it. >> The cookbook pages at >> schematics.sf.net makes no reference to the wiki edition; once you >> find schematics.webhop.net, the author guide is apparently incomplete >> on key topics like creating recipes and editing existing ones; and >> the >> mailing list has contradictory messages about what is going on. > None of this is targeted at anyone other than those of us setting up > the > system, at this point. Everyone is free to contribute ideas, time, > fix > things that are broken, ask questions, whatever. If I can help > anyone with > anything, please just ask. When I click Edit, a password dialogue tells me to Cancel to register, but then it 404s. I used TWikiGuest instead for now, but what did I do wrong? > A big part of the reason that the author guide documentation is > incomplete > is that there are still some unresolved issues. [...] Even creating and editing recipes? OK, fine. If no-one is doing those basic acts yet, the situation is not as daft as I thought. From the list traffic, it seemed that we were being left behind as a flurry of work was done. > My latest idea on this subject is in the topic > AdminCookbookViews. I can see the page, but how do I find other things in this category (if that's the same as what Twiki calls a topic)? Clicking the page title (which gives a list of linking pages on most wikis) doesn't work. > Using a proof of concept to communicate and possibly help move things > forward shouldn't be construed as "presenting a done deal". [...] As I wrote above, that wasn't the impression I'd got. This seemed like a full-blown charge off into the unknown rather than a scouting party. If the cookbook itself hasn't developed yet, or that development is being fed back into the schematics sources, then I'm sorry for getting jumpy and accusing you of railroading. -- 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 06:42:12
|
MJRay wrote: > On 2004-04-20 07:26:13 +0100 Anton van Straaten > <an...@ap...> wrote: > >> I've started a page listing some of the infrastructure items >> we've discussed so far, at: >> http://shizuku.appsolutions.com/twiki/bin/view/Cookbook/AdminOverview > > Now I don't know which Cookbook wiki I am supposed to be using: is > this the one at webhop too? The webhop address is just an alias for the same site. Currently, you can't use the webhop address to generate URLs to link to a specific page from the outside. We'll be fixing that before making the cookbook public, of course. Speaking of which, does anyone have any good ideas for a Schematics domain name? >> There's not a "How to Use Twiki" for authors yet, but the entire >> TWiki docs are there for the browsing. > > This is quite a problem. I have been using wikis since the c2.com one, > but I do not know TWiki and it does not seem very wiki-like, with new > obfuscating jargon (topics?) and markup. Aren't wikis meant to be > simple? Needing to learn Twiki seems another barrier to entry. There's very little to learn. Afaik, at least some of the other recipe contributors were unfamiliar with TWiki before a couple of weeks ago. I think the main thing that's needed is a simple "getting started" writeup oriented to new contributors, and I'm willing to work on that. BTW, if you haven't seen it already, you should check out the TWiki.WelcomeGuest page, which is also linked from the WebHome page. I think the point with TWiki is that some of the utter simplicity of ordinary wikis is traded off for greater ability to manage the content. I think you might find that TWiki actually addresses some of the concerns you've raised. The biggest reason I haven't been worrying about using an annotation system, or people trashing the site, is that the revision history of any page is just a mouse click away (the "Diffs" link at the bottom of the page). The diffs basically give you an annotation-style view of the edits that have been made. >> Re annotations, I've added a topic called AdminAnnotationProposal >> which describes a way we could integrate annotations with the >> current cookbook design, if we want to. > > It sounds very complicated and lots of perl hacking. If you are > confident of being able to do it, I'll take your word for it. It should be easy enough. What are our alternatives? For comparison, the patch to the perl code to hook in the Scheme formatter took all of about three lines of Perl. This one might take a little more, and we might even do it in Scheme if that makes sense. > When I click Edit, a password dialogue tells me to Cancel to register, > but then it 404s. I used TWikiGuest instead for now, but what did I do > wrong? I'll check that out. In the meantime, if you go to the TWiki.TWikiRegistration page, you can register there. It's also linked to from the first link on the AuthorGuide page. FYI, I checked that you can use MJRay as a name, and putting double brackets around references to it will cause it to be recognized as a link. Also, "MJR" will autolink. >> A big part of the reason that the author guide documentation is >> incomplete is that there are still some unresolved issues. [...] > > Even creating and editing recipes? OK, fine. If no-one is doing those > basic acts yet, the situation is not as daft as I thought. Creating and editing recipes is very simple, and people have been doing it. Take a look at a few existing recipes for a model. The unresolved issues mainly relate to how to structure the coobook for both online viewing and other publishing formats. >> My latest idea on this subject is in the topic >> AdminCookbookViews. > > I can see the page, but how do I find other things in this category > (if that's the same as what Twiki calls a topic)? A topic is just a page with a wikiname. There's a link at the top of the page that reads "Ref'd By". Click that to see which other topics reference the current page. At the top right, there are also links to the current topic's parent pages, although those are only meaningful if the page was created from a page that makes sense as a parent, or if someone bothered to set the parent (via the "More" link). >> Using a proof of concept to communicate and possibly help move things >> forward shouldn't be construed as "presenting a done deal". [...] > > As I wrote above, that wasn't the impression I'd got. This seemed like > a full-blown charge off into the unknown rather than a scouting party. > If the cookbook itself hasn't developed yet, or that development is > being fed back into the schematics sources, then I'm sorry for getting > jumpy and accusing you of railroading. Not sure what you mean by "being fed back into the schematics sources". Which sources? Everything we've done so far is on the Twiki site, and is revision controlled by Twiki. If we want to keep a copy of the wiki page source in the Schematics cvs, we could probably do that with cvsup. As to whether we're a scouting party or a full-blown charge into the unknown, perhaps it's a bit of both. If we need to, we'll do a full-blown retreat with equal enthusiasm, I'm sure. If it makes you happy to imagine us as a bunch of Keystone Kops, that's your prerogative, but I'm used to getting things done and making them work, and I'm having a hard time being frightened by this particular unknown. What's our worst-case scenario? Anton |
From: MJ R. <mj...@ds...> - 2004-04-22 12:12:42
|
On 2004-04-22 07:37:19 +0100 Anton van Straaten <an...@ap...> wrote: > Speaking of which, does anyone have any good ideas for a > Schematics domain name? Domains based schematician and plt-?schematics are available. > There's very little to learn. [...] There are specific non-wiki concepts to learn. > I think the point with TWiki is that some of the utter simplicity of > ordinary wikis is traded off for greater ability to manage the > content. I > think you might find that TWiki actually addresses some of the > concerns > you've raised. I might, when I have time to penetrate the jargon, but how does this agree with the "wiki is lightweight" reasons? > [...] The unresolved > issues mainly relate to how to structure the coobook for both online > viewing and other publishing formats. ...that is, how to actually use the entered data to produce what I thought was the desired output? >>> My latest idea on this subject is in the topic >>> AdminCookbookViews. >> I can see the page, but how do I find other things in this category >> (if that's the same as what Twiki calls a topic)? > A topic is just a page with a wikiname. [...] Why not call a page a page? Or does this split jargon arise because there are pages which aren't wiki pages? > Not sure what you mean by "being fed back into the schematics > sources". Which > sources? The CVS ones held on the schematics project site that this was seeded with. > [...] What's our worst-case scenario? At a guess: everything entered into the site needs to be rewritten in a format useful for producing a cookbook release and, unnoticed, no-one does that work while Evil Geniuses find some way to subvert the cookbook, replace recipes with useless-but-sensible-looking ones, introduce hard-to-remove spam and remove the old revisions. -- 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 19:33:03
|
MJ Ray wrote: >> There's very little to learn. [...] > > There are specific non-wiki concepts to learn. > >> I think the point with TWiki is that some of the utter >> simplicity of ordinary wikis is traded off for greater >> ability to manage the content. I think you might find >> that TWiki actually addresses some of the concerns >> you've raised. > > I might, when I have time to penetrate the jargon, but > how does this agree with the "wiki is lightweight" > reasons? It's a tradeoff. We're already significantly more lightweight than we were, and I find it hard to imagine being much more lightweight while still maintaining some modicum of ability to manage the content effectively. I'd be happy to be proved wrong. >> [...] The unresolved >> issues mainly relate to how to structure the coobook for both >> online viewing and other publishing formats. > > ...that is, how to actually use the entered data to produce > what I thought was the desired output? We mainly seem to be talking about arranging a bunch of recipe pages. It's not rocket science. I can't think of any strong reasons not to be writing recipes while we improve the organization aspect, for example. > Why not call a page a page? Or does this split jargon arise > because there are pages which aren't wiki pages? I would guess it's because "page" is ambiguous and could apply to any web page anywhere. Also, the term "topic" reflects a focus on content, rather than presentation. Topics can include other topics, so the topic<->page connection is not perfectly one-to-one. >> Not sure what you mean by "being fed back into the schematics >> sources". Which sources? > > The CVS ones held on the schematics project site that this was > seeded with. Afaik, the original WebIt sources are now essentially obsolete. I'm not aware of any plan to convert back to that format. We could easily store either the TWiki source pages or the generated HTML in the CVS if that's considered desirable. A point about the source format being TWiki's: a big reason I'm not very concerned about format conversions in future is that the source format in TWiki, much like other wikis, is such a basic, almost plaintext format. The recipes written so far consists mainly of headings, paragraphs, some very basic text formatting, and blocks of source code, and is easy to parse automatically. At the same time, the output is sufficiently well formatted as to produce something that could conceivably be used directly for printing to PDF, and possibly even for book publishing - for example, using a CSS stylesheet to produce the desired fonts and other formatting required by the book. However, if some kind of conversion is needed for the book publishing case, I don't see that as being particularly problematic, because the format is so transparent. >> [...] What's our worst-case scenario? > > At a guess: everything entered into the site needs to > be rewritten in a format useful for producing a cookbook > release and, unnoticed, no-one does that work while > Evil Geniuses find some way to subvert the cookbook, > replace recipes with useless-but-sensible-looking ones, > introduce hard-to-remove spam and remove the old revisions. I've addressed the format question above. My feeling is that producing book-style output is something we're going to have to pay ongoing attention to, as the cookbook evolves. If no-one does that, then sure, we could have problems. The solution to that is: let's pay attention to it. If you feel some more formal process is needed here, it's up to you to either suggest an approach, or convince someone else to come up with something. As for Evil Geniuses, afaict the revision control doesn't allow you to remove old revisions without administrator access to the host machine. Mirroring to the Schematics CVS might also help there, or some of us could keep individual backups. As long as we're not using an annotation approach, we'll need to keep an eye on recipe quality. TWiki has some tools to support that, such as the ability to email lists of changed topics and new signups, and of course it supports an RSS feed. If recipe quality seems to be being compromised, then certainly switching to an alternative control mechanism would make sense. Once again, on the subject of how we know we've reached that point, if you feel we need formal guidelines, go ahead and propose some. Anton |
From: MJ R. <mj...@ds...> - 2004-04-23 15:28:40
|
On 2004-04-22 20:33:00 +0100 Anton van Straaten <an...@ap...> wrote: > I would guess it's because "page" is ambiguous and could apply to any > web > page anywhere. Also, the term "topic" reflects a focus on content, > rather > than presentation. Topics can include other topics, so the > topic<->page > connection is not perfectly one-to-one. It sounds that topic<->topic is not one-to-one either, from your description. I think this reflects a focus on technicalities, rather than content. > A point about the source format being TWiki's: a big reason I'm not > very > concerned about format conversions in future is that the source > format in > TWiki, much like other wikis, is such a basic, almost plaintext > format. TWiki suffers from semantically-significant line noise. The WebIt sources were ignored and forgotten about, but are basically easy to read and comprehend. Little seems to be done to prevent the problem of forgetting about them from happening again, while the partly-solved problem of formatting is being solved afresh again. -- 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: Brent F. <bf...@pa...> - 2004-04-23 16:32:59
|
I'm going to break my silence with a few (probably uninteresting) comments: --- MJ Ray <mj...@ds...> wrote: > > A point about the source format being TWiki's: a > > big reason I'm not very concerned about format > > conversions in future is that the source > > format in TWiki, much like other wikis, is such > > a basic, almost plaintext format. > > TWiki suffers from semantically-significant line > noise. The WebIt sources were ignored and forgotten > about, but are basically easy to read and comprehend. > Little seems to be done to prevent the problem of > forgetting about them from happening again, while > the partly-solved problem of formatting is being > solved afresh again. I think it's great that Noel and Anton have taken the initiative to create the new Cookbook site. It's quite nice looking, and I'm sure after playing with it for a few minutes I'll be capable of adding new information and thereby inculcate my bad habits and technique in new generations of Scheme users. However, I must admit to being a bit saddened that the original WebIt! sources were abandoned. I really liked the idea of creating a Scheme document that was entirely authored and published using Scheme software. I would be perfectly happy to discover that the new Wiki was running under the Scheme wiki software, but I'm pretty sure this is not the case. Now, I've been basically a bump on a log, and haven't contributed anything concrete recently so please take my comments in the relatively "all-talk, no action" fashion they should be! :-) -Brent |
From: Anton v. S. <an...@ap...> - 2004-04-23 18:22:11
|
Brent Fulgham wrote: > However, I must admit to being a bit saddened that the > original WebIt! sources were abandoned. I really > liked the idea of creating a Scheme document that > was entirely authored and published using Scheme > software. I would be perfectly happy to discover that > the new Wiki was running under the Scheme wiki > software, but I'm pretty sure this is not the case. You're right, it's not running a Scheme wiki, although all the Scheme source code formatting is now being done by a PLT servlet. The reason we're not using a Scheme wiki is simply that we didn't have something already available that could do everything we needed. Waiting to develop something wouldn't be the quickest way to get a cookbook going. I think we can migrate towards greater use of Scheme. I've hinted in this direction on the AdminCookbookViews page. In thinking about how that should work, I noticed that something pretty similar to WebIt's markup could work well for defining our index layout, and I've just added a comment to that page giving an example of what I'm thinking of. In the longer term, we have a bunch of tools that we could exploit and use to make a more Scheme-based site, including Moshi, WebIt!, SSAX, HTMLPrag, SchemeRSS. The current Scheme-based source code formatting was partially intended as a proof-of-concept of integrating Scheme usage with the TWiki server. That's worked well, and the approach can be extended to do other things with Scheme. If we reach a point where we have entire pages served by Scheme, it would be easy enough to integrate things so that some pages are served directly by Scheme, and others by the TWiki server. We could use the InterWiki mechanism to allow wikilinks between the two. > Now, I've been basically a bump on a log, and haven't > contributed anything concrete recently so please take > my comments in the relatively "all-talk, no action" > fashion they should be! :-) That's fine with me. I don't want my previous comments to be misinterpreted as thinking I don't want to hear from anyone who isn't offering action. The more opinions we hear, the better we can make the cookbook. My earlier reactions were to some comments which didn't seem constructive to me. Anton |
From: Noel W. <noe...@ya...> - 2004-04-27 09:07:10
|
--- Brent Fulgham <bf...@pa...> wrote: > However, I must admit to being a bit saddened that > the > original WebIt! sources were abandoned. I really > liked the idea of creating a Scheme document that > was entirely authored and published using Scheme > software. I would be perfectly happy to discover > that > the new Wiki was running under the Scheme wiki > software, but I'm pretty sure this is not the case. I share your sorrow. The one thing that keeps from hacking Moshi till it does what we want is that I really don't feel like implementing an access control system. Everything else: rcs, multiple webs per wiki, backlinks etc should be easy. Rest assured that the work you did on the WebIt sources lives on. I'm currently kicking it around for use in pseudoscribe (src/apps/pseudoscribe), which I hope will become a good enough documentation system for the next SchemeUnit manual and revive SchemeDoc as well. Noel ===== 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: Anton v. S. <an...@ap...> - 2004-04-28 08:21:28
|
Noel Welsh wrote: > --- Brent Fulgham <bf...@pa...> wrote: >> However, I must admit to being a bit saddened that >> the original WebIt! sources were abandoned. I >> really liked the idea of creating a Scheme document >> that was entirely authored and published using Scheme >> software. I would be perfectly happy to discover >> that the new Wiki was running under the Scheme wiki >> software, but I'm pretty sure this is not the case. > > I share your sorrow. The one thing that keeps from > hacking Moshi till it does what we want is that I > really don't feel like implementing an access control > system. Everything else: rcs, multiple webs per wiki, > backlinks etc should be easy. I don't think access control should be that difficult to implement. Should we consider planning to migrate towards a Scheme-based solution when we have something ready? As I've said, I think it's feasible to continue to create recipes, build up cookbook content and convert it to another format later. If we have some idea of what format we're planning to move to, that'll make it even easier. Anton |
From: Anton v. S. <an...@ap...> - 2004-04-23 18:24:31
|
MJ Ray wrote: > TWiki suffers from semantically-significant line noise. In that sense, how is it different from any other wiki that supports text markup? In the end, it's just a format, which is parseable and transformable. There are at least two reasons we're interested in this format: (1) like other wiki formats, it has proved in practice to be easy for people to deal with and produce content with; (2) it's supported by an infrastructure that offers various features which we want (enumerated in one of my last few posts). > The WebIt sources were ignored and forgotten about, > but are basically easy to read and comprehend. IMO, the wiki format is less cluttered and easier to deal with for the purposes of actually writing and editing the content of recipes. For example, we no longer have to wrap each paragraph in a (paragraph [...]) expression. You previously wrote "I have been put off [updating the Cookbook] because of the need to learn things I don't know and something I won't use commercially (WebIt)". Perhaps you feel the same way about Twiki, but then the same would be true of any system we choose, other than a wiki you're already familiar with. Afaict, none of those seemed to have the kinds of features we wanted. > Little seems to be done to prevent the problem of > forgetting about them from happening again, I don't understand this concern. Making the content available in a wiki-like format is specifically intended to make it more accessible, get more people interested, and make it much less likely that it be forgotten about. The activity so far is initial evidence of success here. > while the partly-solved problem of > formatting is being solved afresh again. The formatting of actual recipes is solved by the current solution. Overall structuring is something that would presumably also have had to be dealt with using WebIt, in order to provide both a good online presentation as well as other delivery formats. Anton |
From: MJ R. <mj...@ds...> - 2004-04-23 22:36:19
|
On 2004-04-23 19:24:27 +0100 Anton van Straaten <an...@ap...> wrote: >> The WebIt sources were ignored and forgotten about, >> but are basically easy to read and comprehend. > IMO, the wiki format is less cluttered and easier to deal with for the > purposes of actually writing and editing the content of recipes. For > example, we no longer have to wrap each paragraph in a (paragraph > [...]) > expression. You aren't contradicting me, so I assume you agree? > You previously wrote "I have been put off [updating the Cookbook] > because > of the need to learn things I don't know and something I won't use > commercially (WebIt)". Perhaps you feel the same way about Twiki, but > then the same would be true of any system we choose, other than a wiki > you're already familiar with. Afaict, none of those seemed to have > the > kinds of features we wanted. Yes, Twiki shares the previously mentioned problems, but maybe they're unavoidable for this task. Twiki is actually worse on this aspect, though: it's not even comprehensible without a sort of dictionary to hand. I would never have guessed trying --++-- for a heading, for example. >> Little seems to be done to prevent the problem of >> forgetting about them from happening again, > I don't understand this concern. Making the content available in a > wiki-like format is specifically intended to make it more accessible, > get > more people interested, and make it much less likely that it be > forgotten > about. The activity so far is initial evidence of success here. There is no evidence for this yet: it's simply too early. However, we still have no activity measures and rely on the people working on it to tell us when they no longer have time again, which still seems a bit unsafe. I suggest measuring and reporting activity to schematics-development at some reasonable interval, preferably automatically, so we can act if it says "Schematician edits: 0%" or whatever we think is a questionable level. -- 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/ |