[plug] unsubscibe (newbie's perspective)

[Mike]

At 11:12 AM 26/3/2001 +0800, Greg Mildenhall rote:
>On Mon, 26 Mar 2001, Mike wrote:
>> Are people forgetting something here ?
>> a.	Computers can be programmed to perform various tasks,
>> 	easy to program it to handle unsub requests from the list
>> 	members as well as via an admin list. Simple logic could
>> 	handle the very requests (and several exceptions) that
>> 	have recently occured.
>
>ROFL. Your faith in computers is touching, but unrealistic. :(

I have no particular faith in a piece of hardware, I do have faith
in the ability of enthusiastic individuals and their tools.

>> b.	Wouldn't it be a nice demonstration of the powers of linux
>> 	and cooperative intent of the group (vis a vis linux came
>> 	together via open source cooperation), if the list software
>> 	were expertly programmed to minimise non-effective list
>> 	traffic - such as unsub requests, spam, bounces etc etc
>
>We don't seem to get many spams or bounces, thankfully. (well done, Matt)
>The problems only start when you have actual list-members (the people we
>trust, basically) doing foolish things. The trick is not to subscribe
>fools, or to subscribe then educate them. That's only slightly easier.

Again you make an assumption a 'fool' is incapable of becoming an
expert and a helpful member of a list, this is not the real world.

>> 	Note: Its occured to me that to handle erroneous traps
>> 	on unsub requests, the list s/w email the person who
>> 	made the request informing them of being unsubbed, that
>> 	way if some poor plebe stumbles upon an unsub request whilst
>> 	making a bonafide list message then they get alerted.
>
>By which time they have missed how many messages? A big inconvenience to a
>list-member instead of a small inconvenience to an ex-list-member? Why?

Look at how the logic can eb constructed to handle this, they wouldn't
miss messages according to a set of exception conditions, hey rather
they simplistic feeble criticism - why not construct a paradigm so
they don't lose em ?

>> c.	Linux is slowly getting some recognition and we need all the
>> 	newbies we can get and then some more,
>
>Not sure why you would say this. I certainly don't need newbies. :)

You are only one member of this list, are you suggesting this list
does not need any new members - if so why ?

>> the last thing you want to do is restrict in any way acess to learning
>> and discussing with others linux and its issues.
>
>Doesn't anyone here favour quality over quantity? The signal/noise ratio
>is the standard test of a forum's effectiveness, and for good reason.

Who's judgement of quality ? This is a discussion list about linux
isn't it ? Whos judgement of signal vs noise, I am suggesting a way to
reduce noise - instead of criticism why not think about improving it ?

>> 	IMNSHO: REstricting subscriptions is like restricting education
>> 	(which should be totally free - and I'm a capitalist).
>
>So you are not in favour of excluding children from a school when their
>behaviour prevents the effective education of other children?

I am in favour of free education, I never said anything about bad
behaviour, "When did you stop beating your wife ? "

I a child is bad behavedm I would be in favour of them getting the
very same education as other children, under the advisement of
behavioural psychologists it would be appropriate to limit their
negative effects on other children and this does *not* mean locking
them away - afterall the other children must also learn how to
deal with bad behaviour, there are ways to handle this and this is
not the forum for this discussion item.

>> 	Here's a thought: For newbies, the list s/w append a note
>> 	re where the FAQ is (as well as unsub info) for a rolling
>> 	average number of messages. Say if person 'x' only emails
>> 	once a month then they get a suffix note re FAQ and Unsub,
>> 	if people send to the list more then 3 times a month or
>> 	so then they get no suffix FAQ or unsub info.
>> 	In fact, the list s/w should also send a FAQ/Unsub to anyone
>> 	once each 6 months etc etc This is not mutally exclusive
>> 	with list s/w handling unsubs sent to list,
>
>If people receive something more than once, they will only read it the
>first time, regardless of whether they comprehended it initially. I am
>Jack's bitter experience.

Not necessarily - assumes (partly) a static model of human behaviour,
it would be an interesting experiment in respect of peoples response
as to how active they were and *then* whether they noticed footers
that changed, etc etc

>> Its amazing that people who have programming experience tend to be
>> less aware of their impact on others and can become so arrogant to assume
>> those without programming experience can not come up with solutions to
>> computer related problems.
>
>and it is equally amazing that people who don't have programming
>experience think that programmers should be able to come up with software
>solutions to social problems.

This is not a social problem - we are discussin reducing list noise
for issues such as unsub requests.

>While on the subject, a programmer understands the merits of out-of-band
>control signalling, but non-programmers seem to arrogantly assume that
>because they don't understand the merit, its not real.

In which context are you referring to 'out of band...', we are not
discussing PID algorithms are embedded systems and in any case please
describe how that is relevant to the issue of unsub noise mails ?

>> I could do it in assembler with a bleedin Z80, it ain't that hard
>> - is it ?
>
>Yes, as a matter of fact, it is.

Oh come on !
Back in 84 I wrote a text search retrieval package and disk drivers for
a 'northstar' winchester 10meg hdisk system - in 64K you could do
a heck of a lot - admittedly at the time I had the benefit of a
pascal compiler with heaps of string operators. To read a subject
and make decisions for a small number of emails is not hard, you
can work out the latency is not mroe then a second or two per email...

Rgds

Mike
PS: I am not suggesting we use a Z80 <cough> todays cpus are fine,