[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: OASIS and XML-DEV
Firstly to thank the several people who have posted constructive solutions to the list. Please continue This is a difficult message for me to write and I ask for consideration and constructive responses. Firstly, I believe in the aims of OASIS and believe we need an organisation to fulfill them. Such an organisation is appropriate to host XML-DEV. I wish to see OASIS continue to be involved with XML-DEV. We have to have a flourishing organisation with these aims. I would like, therefore, to see an outcome where XML-DEVers, OASIS and others see a constructive way forward. I do not wish to judge OASIS's business processes publicly. I am not a member (cannot afford it), and have had no formal business communication with them. I do not meet OASIS members in real-life except very occasionally. Those OASIS staff whom I know personally, I greatly respect. I think we would all agree that OASIS has ambitious aims, that XML is expanding very rapidly, and that they have a great deal on their plate. (Just look at the site map). However I have had no real communication with OASIS since the list moved, and both Henry and I have found that private e-mail has neither solved the problems nor given us an insight into how the organisation works. Therefore everything I say from here on is speculation, and I shall be very careful. I would obviously be grateful for any corrections. Clearly OASIS have committed to support the list and this involves real resources and we should publicly appreciate this. The following suggestions assume that they wish to continue to commit resource (in some form) and that we should try to design solutions which are as cost effective as possible. It seems that there are attractive technical ways of outsourcing some of the list activity which would reduce costs, increase the role of volunteers and improve service. I hope OASIS is sympathetic to these ideas. Ideally I would like us to reach a communally acceptable way forward. Our thinking will have to be done in public, on this list. *** Please therefore make sure that everything you post is constructive and aimed at a win-win for everyone ***. It is not an easy process for some people, because much conventional business is done face2face or over the phone. But I am optimistic, so let's try... Please correct any technical aspects :-) The list activity breaks down into the following. Let us try to refer to this with consistent terminology (capitalised here) if possible... MAILLIST. This is the single essential component. At Imp College it consisted of: 1 LISTSOFTWARE Majordomo and majorcool software. 2 A LISTSERVER machine and OS and 3 SYSTEMSTAFF to maintain 1 and 2 *generically* 4. A LISTMANAGER (Henry) 3 and 4 need not be the same person. 1/2 could be provided by different technologies (e.g. newsgroups, etc.) UK academia has a service (mailbase) for this purpose and we could have used it for free. We judged the facilities provided were not as appropriate as Imp College. Details of the ImpColl setup: Henry had no access to 1/2 other than occasional personal requests to the staff (he could not hack any serverside stuff) Subscription and Unsubscription was automatic BUT: a high proportion of e-mails decay. These throw errors. Assuming there are 10 rogue e-mails and 40 messages/day, Henry got 400 error messages/day. These included failed unsubscriptions. When failed unsubscribers re-failed, they would sometimes post their disquiet to the list! Manual attention was the only solution. This was sometimes trivial, sometimes extremely difficult and Henry became an expert at deciphering mail headers. This is what took the time (4/5 hours per week). *** Anyone offering to run a list should be aware of this - if anyone has a solution, fantastic.*** There was no technical moderation (any member could post any content). It is a tribute to the list that the only moderation is my and other members' comments. If anything serious had arisen we would have had to manual remove a subscriber. Note that it is NOT allowed to remove messages from an archive. *** Note that most of the concerns of list members fall into categories 1/2/3. Thus we need access to facilities on a machine which is: - robust - has high bandwidth - 24/7 support - competent *generic* maillist skills - hopefully - a channel of communication between 3 and 4! Therefore a generic ListServer, properly serviced will solve all the time-critical problems. The ListManager is less time critical in that it only affects subscribers, unsubscribers and errors. Some off-time may be acceptable here (even henry had to sleep). Note also that there was little need for Henry and me to interact on moderation - we have never unsubscribed anyone against their will. Therefore on the assumption that I remain as a moderatorial influence, I do not need to have formal liaison with the ListManager. ***Note that the MailList has to be associated with a domain name (at present xml.org) and there is also a single subscription list of mail addresses. Any transfer of MailList functionality has to address these points. I would very much hope we can retain the xml.org domain name, even if the ListServer is physically and organisationally distinct HOMEPAGE This is not essential, but highly desirable. (We never had it at Imp Coll). It need not have the same physical location or domain name as the ListServer MAILARCHIVE The primary archive is a standard mailbox (is this SMTP?). Henry and I have the 3 year archive from IC in the form that it arrived and as far as we know has every message. *** It is absolutely essential that this is retained for posterity ***. I also think it should be GPLed, with restrictions about how it is edited. In principle any person or org *** subscribed from the beginning *** has a copy of this in their mailbox if they have not deleted any messages. However with 20000 messages it is a fair amount of disk space. HYPERMAIL This requires software which reads the mail as it comes in (or the MailArchive) and creates a threaded display in HTML (or some similar technology - XML :-). At IC they provided hypermail (I think). In principle this need not be on the same site as MailList, and in principle there can be multiple copies or parallel efforts. COMMUNAL RESOURCES We have not had communal resources so far, but I think this is what David Brownell is suggesting. Again they do not need to be coupled to the MailList, HomePage or MailArchive site(s). We have had several suggestions (a few privately). This is not a complete summary. newsgroups, eGroups. Newsgroups (e.g. comp.text.xml) have to set up by a formal vote and I don't think are appropriate. I would like detailed technical comment on the other options, including domain name, subscription list, mailbox, etc. volunteers. MailList. We have had a very promising offer from an individual in a *.org. - his org already runs list technology and their core business is infrastructure - they are complementary, not competitive, to OASIS - they have long-standing and are likely to continue to have this - they could work through the xml.org domain name I therefore believe that the main question is whether X can find the same amount of time as Henry to be ListManager and what happens if/when he leaves the *.org. parallel activities We already have more than one threaded HyperMail (xml.org and e-groups) - I see no reasons why these and others cannot develop in parallel. The same is true of commentaries on xml-dev. I suspect that most of the ideas like David Brownell's do not need formal permission from ListManager or ListServer and individuals or groups are encouraged to develop them on the list Summary I think that some of the technical aspects can be outsourced attractively and without cash costs. I hope that OASIS can find this a positive posting and suggest how they can support some of it. Please be careful, courteous and constructive in your replies P. *************************************************************************** This is xml-dev, the mailing list for XML developers. To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/ ***************************************************************************
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|