next message in archive
next message in thread
previous message in archive
previous message in thread
Index of Subjects
Index of Subjects Hi all, On Wed, 11 Aug 1999 aa935@chebucto.ns.ca wrote: > For IPs, there are additional steps in the procedure. Besides the need > of an editor account (as above), additional forms, and a > training/certification procedure were required to be completed. In the > past, these additional steps were deemed necessary so that web page > installs, updates could be performed competently by the IP editor from > the text browser. Additional resources (web space) etc. were assigned > to the IP organization, dependent upon the fee paid. > > With the advent of FTP service, web page updates can be performed, in > most cases, without the need to know the nuances of the text > environment. Which begs the question - 'why is an IP member required to > follow a projected sign up procedure?'. Could IPs be viewed as other > class(es) of member (business, organization)? > > If the proposition that membership should be expanded to include an > organization level and a business level, then the procedure for joining > CCN could be streamlined into one procedure, with the appropriate fees > and services. > The question for discussion is: > - should the IP stream and the general membership stream be merged? My $0.02: 1) IP Registration Process With a sufficient amount of work I'm sure we could integrate IP registration as some sort of an option/offshoot of the user registrations process. The question is why? A) Doing this would involve re-writing all the pages, forms and CGI scripts that collect all the information and channel them into IP and User databases (& elsewhere?) and all the associated bells & whistles (e.g. IP Response Letter). Sounds like a lot of work to me; lots of debugging involved to make sure everything works, etc. B) In any event, we ask for very different sets of information from users and IPs so streamlining input wouldn't seem to be consequential. C) We require IPs and individuals to sign different agreements with different obligations and responsibilities. D) What's to be gained? Why not have (as we do) two separate gateways for two different entities? Where's the advantage? 2) IP Training Comments viz-a-viz the new CCN FTP service (IP directories being FTP installable; Chebucto Plus) and Training miss the point that IP Training has already introduced a training option to take this into account. My understanding is that IPs who propose to administer their files via FTP are not required to learn material which does not pertain to them. Bob Adams can provide details. It's a separate question of whether the CCN ought to be training people at all. There are, as I've pointed out, both historical reasons why this is so, and a community/ideological position that the CCN took at its inception that training was a worthwhile and desirable thing to do. One could, of course, argue that we shouldn't bother (let IP's pay their money and take their chances ... ;-> ) but my inclination is towards feeling that it is a worthwhile thing to do even if there is a sense that what is taught should be re-evaluated. Ensuring that IP Editors know what they are doing ought to save us lots of headaches down the line. In any event, Training is an issue entirely separate from the pathways of the registration process. 3) RCS On Thu, 12 Aug 1999, Andrew D. Wright wrote: > We also lose the troublesome RCS system which while useful in > its day now has become dated. No other ISP has anything like this in > place and I for one will not miss having new pages being replaced by old > pages because the system hiccups. This also greatly simplifies any new > organization's learning curve as I have heard more than once from IP > _veterans_ RCS horror stories. I'd like to hear the perspectives of others on RCS. I've certainly never considered it either troublesome or dated. It allows people to do on-line editing which I consider extremely useful and an advantage that the CCN has over most commercial ISPs. If anything I've regretted that we haven't really harnessed the power of RCS and have never really built a front-end to make use of its functionality. I don't know if there are better or simpler ways to do this but I'd certainly regret seeing the CCN abandon on-line editing. If anything, I'd like to see RCS functionality even better implemented on the CCN. 4) IP 'dropouts' and the IPDB On Thu, 12 Aug 1999, Andrew D. Wright wrote: > As we now know, the majority of dropouts from the IP process > for the last three years have been through not completing > our IP creation process. (see Appendix) I'm not sure what this means (it sounds circular) however, in any event, the information in IPDB can't tell one anything about why applications don't proceed to completion (i.e. IP creation). This is an area I know really well since I think that over the years I have probably communicated with every single IP and IP application that has ever existed. There are several point to be made: 1) I can't recall an instance where the IP *process* has ever resulted in an IP not being created. 2) In a very small number of instances (a handful) people have objected to taking IP Training and have either withdrawn their applications or have not bothered to pursue them to completion. The vast majority of IP applications have proceeded smoothly through IP Training, in some cases very pleased to have been part of the process. In most instances where people have had legitimate concerns to doing so (short timelines; already know the material, etc.) we have made exceptions or accommodations for them. I doubt that this has been a factor in more than 2-3% of applications. 3) The vast majority of applications that 'stall' (i.e. do not proceed from IP Application to IP Creation) - and I have corresponded with almost every single one of such applications - result from people who make applications on the basis of 'wishful thinking', i.e. who don't necessarily seriously mean to pursue the creation of a website. In some instances applications are abandoned because people lose interest; the IP goes belly up; the organization decides to situate elsewhere; the IP Editor is unable to convince the organization to proceed; or the IP Editor doesn't really have the time to do it. 4) In any event the IPDB (useful as it is) doesn't really have the data to allow an analysis since: a) Over the years I have purged the vast majority of inappropriate, defunct, expired, duplicate, test, etc. applications; b) The status categories that are available to indicate the fate of an IP are both inadequate in (in some instances) don't really correspond with the way we manage our IPs. They are: trained; withdrawn; inactive; active; static; moving; moved; removed. 'Static' doesn't exist. We've never used 'moving' . I'm not sure what 'removed' could mean. Applications that are 'withdrawn' are usually purged from the IPDB. Other potentially useful designations don't exist. These consequence is that these status categories have been used inconsistently, and incompletely if (in some cases) at all. Thus we don't really collect useful information from IPs about why they proceed through the process (and what they like or don't about it) nor (for those that don't proceed to completion, why it is