nms-cgi-devel — Developers discussion for NMS CGI programs

[Nms-cgi-devel] Re: [Nms-cgi-support] form could not be received

[Dave C. <da...@da...>]

On Wed, Jan 15, 2003 at 11:15:05AM +0530, PARKINS ENTERPRISES <www.parkins.netfirms.com> (pa...@si...) wrote:
> Dear Sir,
> 
> It is still not working

Ashish,

There's not really very much we can do to help you. You'll need to work
out what the correct URL for the script is. Probably the tech support
people at your web hosting service will be able to help you with this.

When replying to this email, please ensure that you use the "reply-all"
feature of your email program. That way your email will go to the
nms support email address (nms...@li...) and
everyone on the team will be able to help you.

Dave...

> ----- Original Message -----
> From: Dave Cross <da...@da...>
> To: ashish <pa...@si...>
> Cc: <nms...@li...>
> Sent: Wednesday, January 15, 2003 12:59 AM
> Subject: Re: [Nms-cgi-support] form could not be received
> 
> 
> > On Tue, Jan 14, 2003 at 10:31:14AM -0800, ashish (pa...@si...) wrote:
> > > Below is the result of your feedback form.  It was submitted by
> > > ashish (pa...@si...) on Tuesday, January 14, 2003 at 18:31:07
> >
> > --------------------------------------------------------------------------
> > >
> > > description: Dear sir,
> > >
> > > On my website www.mehtaonline.com/contact.html
> > >
> > > After filling the form t"the page could not found" message is displayed
> > >
> > > Please let me know how to correct the error.
> >
> > Your form is configured to use the formmail script at:
> >
> > http://www.mehtaonline.com/cgi-sys/formmail.pl
> >
> > This address doesn't exist. Are you sure it's right? The 'cgi-sys'
> > part seems unusual. 'cgi-bin' would be more usual.

-- 
  And crawling on the planet's face, some insects called the human race
  Lost in time, and lost in space. And meaning.

Re: [Nms-cgi-devel] nms project - moving forward

[Olivier D. <dr...@sh...>]

On Tue, Jan 14, 2003 at 07:27:39PM -0800, Dan Kegel wrote:
> Neil Williams wrote:
> >On Tuesday 14 Jan 2003 1:47 pm, Wizard wrote: ...
> >>is a self-help bulletin board by end-users, where questions are posted by
> >>and support is offered by the users themselves. This seems to me to be an
> >>excellent means of supporting our products, and might even be able to be
> >>done with WWWBoard & SimpleSearch scripts to manage it. If done correctly,
> >
> >
> >That will certainly speed up the development of wwwboard and in particular 
> >wwwadmin! 
> 
> Um, how's that different from a mailing list with a searchable
> archive?  Do people hate mail that much?

It's for the users, not for us. It's easier for users to drop-in and
post a message on a board than going through a sign-up process and
getting your mailbox clogged-up with tons of emails. It's also easier to
reply to than an archived list for those who aren't signed up.

I also like the fact that we could use our own wwwboard and wwwadmin to
give it some rigourous testing.

-Olivier

-- 
                  __-/|    ? ?     |\-__
             __--/  /  \   (^^)   /  \  \--__
          _-/   /   /   \ / ( )  /   \   \   \-_
         /  /   /  /     ~(  ^^ ~     \  \   \  \
         / Oli Dragon    dr...@sh... \
        /  Sfwr Eng III  (  McMaster University  \
        /  /  /     __--_ (   ) __--__     \  \  \
        |  /  /  _/        \_ \_       \_  \  \  |
         \/  / _/            \_ \_       \_ \  \/
          \_/ /                -\_\        \ \_/
            \/                   -)         \/
                                *~
 ___--<******************************************************>--___
[http://pgp.mit.edu:11371/pks/lookup?search=olivier+dragon&op=index]
 ~~~--<******************************************************>--~~~

Re: [Nms-cgi-devel] nms project - moving forward

[Dan K. <da...@ke...>]

Neil Williams wrote:
> On Tuesday 14 Jan 2003 1:47 pm, Wizard wrote: ...
>>is a self-help bulletin board by end-users, where questions are posted by
>>and support is offered by the users themselves. This seems to me to be an
>>excellent means of supporting our products, and might even be able to be
>>done with WWWBoard & SimpleSearch scripts to manage it. If done correctly,
> 
> 
> That will certainly speed up the development of wwwboard and in particular 
> wwwadmin! 

Um, how's that different from a mailing list with a searchable
archive?  Do people hate mail that much?
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

[Nms-cgi-devel] Re: [Nms-cgi-support] FFA tweaklet

[Nick C. <ni...@cl...>]

On Tue, Jan 14, 2003 at 08:45:50AM -0800, Angus Scott-Fleming wrote:
> 
> Suggest you change the line: 
>  
> Sorry, this link is already in the Free For All Link Page 
>  
> to read  
>  
> Sorry, this link is already in the $linkstitle 

This seems reasonable to me - objections anyone ?

--
Nick

[Nms-cgi-devel] Moving Ahead - pt 2

[Dave C. <da...@da...>]

Thanks for all your comments. Rather than reply to each point individually
here's an idea of what I'm now thinking.

I'd hate to lose people like Nick Clark from the devel list. He might not
say much, but when he does it's always worth listening to :) So I agree
that closing the devel list is a bad idea.

Support - I still like the idea of having people whose responsibility
it is to answer support emails on a rota system, but I do agree with 
what Nick and Simon said about even our worst efforts being better than
Matt's current level of support. So how about this:

1/ Some sort of SLA on the web site saying that we intend to respond to
all emails within 24 hours.

2/ The individual script owners still assign a support rota within their
group, but that person has the job of "mopping up" - that is checking
for emails that haven't been answered in 18 hours and posting a reply
(even if that reply is "the expert on that problem will be back online
in 12 hours".

3/ The script owners need to ensure that more people in their group
are skilled enough to answer support emails.

4/ The script owners can decide on their own rules about how to avoid
the multiple reply problem for the scripts they are responsible for.
For example Nick Cleaton might say, "no-one should answer a question
on formmail or tfmail in the morning (uk time) until I've got to work
and posted all they replies I drafted on the train".

5/ I also agree that the idea of a "self-support" forum on the website
is a good idea - as long as people from this list monitor it. Do I have
a volunteer to get wwwboard configured to support this?

I think I saw people volunteering to get more involved with simple 
search and wwwboard - which is great. Thanks people :) We also need
someone to volunteer to take on guestbook. Anyone fancy it?

Oh, and I'll take on responsibility for all the other scripts. Each of 
them typically don't need much support.

And Nick, I think your modular ideas are great. Once we've assigned all
of the "team leader" roles, can you please start to talk with them about
how the other scripts can use your ideas.

How does this all sound to you?

Thanks everyone.

Dave...

-- 
  Drugs are just bad m'kay

Re: [Nms-cgi-devel] nms project - moving forward

[Neil W. <li...@co...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 14 Jan 2003 1:47 pm, Wizard wrote:
> OK, here's my two cents. Please let me know if I'm blowing smoke (or any
> other noxious gases ):
>
> is a self-help bulletin board by end-users, where questions are posted by
> and support is offered by the users themselves. This seems to me to be an
> excellent means of supporting our products, and might even be able to be
> done with WWWBoard & SimpleSearch scripts to manage it. If done correctly,

That will certainly speed up the development of wwwboard and in particular 
wwwadmin! I joined the list to learn about these two and to possibly get 
involved but since joining, other areas have become far more pressing and 
there simply hasn't been time, even to keep up with the recent updates. So my 
experience of wwwadmin, in particular, is behind the times - however, I 
haven't seen a lot of discussion on wwwadmin either. 

(end lurk)

I have multiple local copies of wwboard on varying Linux distros (and even 
Windoze) that I can use for testing but the live site needs to have a 
reliable (i.e. not testing mode) installation at all times so I can test 
locally but the tests cannot be on the main site. (Other hostspace I have 
uses a lot of adverts - freebie ISP stuff - and isn't much use for HTML 
testing, only binary storage.)

- - - -- 

Neil Williams
=============
http://www.codehelp.co.uk
http://www.dclug.org.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+JEQRiAEJSii8s+MRAjKlAKCgUir99I3utKxABM2tmbA+FbStJwCfWfV8
FdFQMU7TaEkxrQMCJfRC9uw=
=BLL5
-----END PGP SIGNATURE-----

Re: [Nms-cgi-devel] nms project - moving forward

[Simon W. <es...@ou...>]

On Tue, 14 Jan 2003, Nick Cleaton wrote:

> On Tue, Jan 14, 2003 at 10:02:21AM +0000, Simon Wilcox wrote:
> > On Tue, 14 Jan 2003, Nick Cleaton wrote:
> > 
> > > Having a single person follow each call through is nice for user
> > > comfort, but not optimum for a quick turnaround.  IMO the speed at which
> > > users get a satisfactory answer is the most important thing, as that is
> > > what stops them giving up and using another (maybe less secure) script.
> > 
> > Are we providing support for them or for us ?
> > 
> > User comfort is as important as speed. In most cases a delay of a couple 
> > of hours is not a problem, indeed your posts are often delayed by your 
> > batching so I don't understand that point.
> 
> I agree a delay of a few hours is OK, I was just worried that with
> different people checking their email at different times, these
> internal escalations could add up to much longer delays.

I agree and as long as it is handled back to the user in an open fashion I
think they will acept the delay. i.e. it will be important to let them
know what is happening, that it has been escalated and there might be a
delay in the response.

> [ SNIP MUCH GOOD SENSE ]
> 
> OK, you've convinced me - I withdraw my dissent.
> 
> The only thing in the plan that I still don't like is making nms-dev
> closed - I would prefer the creation of a new closed list.

I agree with you there too, adding extra things is easier than taking them 
away from people.

S.

Re: [Nms-cgi-devel] nms project - moving forward

[Nick C. <ni...@cl...>]

On Tue, Jan 14, 2003 at 10:02:21AM +0000, Simon Wilcox wrote:
> On Tue, 14 Jan 2003, Nick Cleaton wrote:
> 
> > Having a single person follow each call through is nice for user
> > comfort, but not optimum for a quick turnaround.  IMO the speed at which
> > users get a satisfactory answer is the most important thing, as that is
> > what stops them giving up and using another (maybe less secure) script.
> 
> Are we providing support for them or for us ?
> 
> User comfort is as important as speed. In most cases a delay of a couple 
> of hours is not a problem, indeed your posts are often delayed by your 
> batching so I don't understand that point.

I agree a delay of a few hours is OK, I was just worried that with
different people checking their email at different times, these
internal escalations could add up to much longer delays.

[ SNIP MUCH GOOD SENSE ]

OK, you've convinced me - I withdraw my dissent.

The only thing in the plan that I still don't like is making nms-dev
closed - I would prefer the creation of a new closed list.

--
Nick

RE: [Nms-cgi-devel] nms project - moving forward

[Wizard <wi...@ne...>]

OK, here's my two cents. Please let me know if I'm blowing smoke (or any
other noxious gases ):

I was recently asked by a friend to attempt to fix his Phillips Pronto
remote control. Phillips apparently offers little or no support for this
device (I have yet to receive a response to my support request posted last
week sometime). What I did do, was to go to www.prontoedit.com/forums which
is a self-help bulletin board by end-users, where questions are posted by
and support is offered by the users themselves. This seems to me to be an
excellent means of supporting our products, and might even be able to be
done with WWWBoard & SimpleSearch scripts to manage it. If done correctly, I
suspect that over time this sort of system could dramatically reduce the
number of support requests that get directed to the list (under the "Getting
Support" section, we ask the user to try the self-support first, and if that
fails then email the support list). This would also act as the knowledge
base that someone else mentioned.

Just a thought,
Grant M.

Re: [Nms-cgi-devel] nms project - moving forward

[Simon W. <es...@ou...>]

On Tue, 14 Jan 2003, Nick Cleaton wrote:

> On Tue, Jan 14, 2003 at 12:32:49AM +0000, Simon Wilcox wrote:
> > 
> > 1. I don't think we should be sending multiple, possibly contradictory 
> > messages to new users. I would prefer a more consistent approach.
> >
> > 2. I don't think it is a good use of resources to duplicate the support 
> > effort.
> 
> Both valid points, but are those considerations important enough that we
> should be sacrificing turnaround times to meet them ?  Maybe they are.

I believe so. As you already noted, we are far in advance of any 
alternative and I'm not convinced that raw speed needs to be our goal. 
Perception is important too.

> > I would rather know that it is my $timeperiod to respond to support calls 
> > and that I should be paying attention to the list. When $timeperiod is 
> > over i would carry on with any open calls but someone else would take over 
> > the new ones.
> 
> Having a single person follow each call through is nice for user
> comfort, but not optimum for a quick turnaround.  IMO the speed at which
> users get a satisfactory answer is the most important thing, as that is
> what stops them giving up and using another (maybe less secure) script.

Are we providing support for them or for us ?

User comfort is as important as speed. In most cases a delay of a couple 
of hours is not a problem, indeed your posts are often delayed by your 
batching so I don't understand that point.
 
> Many times, one of us has answered an initial query with a request for
> further information, and another has answered the reply with the
> solution.  This is a good thing IMO.

The solution is a good thing, the confused message is not IMO. I think
that it has the potential to make the problem (of not enough support)  
worse not better as people decide not to answer queries because they
expect that someone will come through with a correct answer.

This is part of the reason why a knowledgebase of some sort is a good 
idea, it will provide people with a better resource of solutions to 
provide on the first attempt.
 
> > As it is, it is all too easy for me to slack-off knowing that the calls
> > will probably get answered by Nick. This isn't good but as you say, we all
> > have other demands on our time. If you're going to answer the call anyway,
> > why do I need to spend the time ?
> 
> Because you answering it now is better in terms of turnaround time than
> me answering it later.

Except that human nature suggests that all that will happen is that 
everyone will leave it to you to answer the question. Look at the list 
traffic - this is already happening. I don't believe it is sustainable for 
very long.

> > In respect of escalations, I feel bad that when I had reached the end of 
> > my knowledge there was no backup to help get the call resolved. Giving 
> > explicit ownership to individuals helps to encourage that support. 
> > Handled correctly with the user, they should understand that more help is 
> > needed and the developer should actually have more time to help with such 
> > things if they are not busy answering lots of other calls.
> 
> You're talking about the TFmail upload problem, right ?  I looked at that
> (quite hard) but I couldn't think of anything that you hadn't already tried.
> The escalation method of posting to nms-dev *didn't* let you down there - I
> would have failed just the same had it been escalated to me via a fancy
> ticketing system.

I don't care about me, I do care about the user who didn't receive a 
solution to his problem. He will now tell 10 of his friends about the 
failure of NMS to run on his system. The fastest turnaround in the world 
will not help us if people perceive the support to be shoddy.

I don't care about fancy ticketing systems either. I did consider the 
merits of something like RT but they don't provide much over what we have 
in the list so it's not really worth the effort.

The list DID fail me though. Not one person responded to me, even to say 
that they couldn't find anything either. People don't like living in a 
vacuum. The collective mind of NMS was unable to go back to this user with 
even one further question. Not very impressive.
 
> > I'm not sure that closing the dev list will help establish a community but 
> > I do think there needs to be an invite-only list of people that drive the 
> > development of the project.
> 
> We could do that with CC in email with our leader posting the outcome to
> the dev list as a policy announcement, couldn't we ?

If that's the way that works best for everyone then yes but I'd suggest 
that you would lose the group memory that comes from having a list archive 
and that getting new members up to speed would be that much harder. YMMV.

As an aside, to hopefully illustrate my feelings here, this mornings 
examples of double posting perfectly encapsulate what I've been saying.

Having taken a few minutes to respond to overnight emails, mostly by 
requesting further information, Nick then delivered his batch of emails 
answering the same questions, generally in ways better than I managed.

I've spent about 30mins so far on composing this reply. Where is my 
motivation to continue answering support requests ?

If I had not responded, the answers would have been forthcoming at about 
the same time. No speed improvement there.

If I had not responded, the answer received would have been less confused 
than it was by me responding.

My conlusion seems to be that my contribution is superfluous.

My question is, how long can one man continue to support the entire list ? 
At first it was Dave, all we've done is move the burden onto Nick. I just 
don't see how that is sustainable so I've suggested ways to spread the 
burden and provide Nick with more support. I guess it's up to you how you 
choose to use those ideas.

Simon.

Re: [Nms-cgi-devel] nms project - moving forward

[Nick C. <ni...@cl...>]

On Tue, Jan 14, 2003 at 12:32:49AM +0000, Simon Wilcox wrote:
> > Our current standard of support is less than perfect, but I hope you'll
> > agree that it's a lot better than none at all, so it's still a big win
> > over Matt's scripts.
> 
> Definitely but I think that Dave is right to consider how we organise the 
> group to go forward in a sustainable fashion and to do it before it 
> becomes really critical.

fair point.

> > > These groups will also be responsible within themselves for assign rotas
> > > of people who will deal with support issues. These will designate a
> > > "first line support" person. This person will be able to call on other
> > > people within the group to help them solve problems that they can't work
> > > out on their own.
> > 
> > That would be a good idea if we all did this 9 to 5, but given that we
> > don't, internal escalations are really going to kill support turn around
> > times.
> > 
> > Anything that moves away from the existing scheme (first person who
> > both sees the question and knows the answer replies) is going to
> > extend turnaround times as far as I can see.
> > 
> > If people are ignoring support requests to which they know the answer
> > because they aren't in the right group then turn around times will be
> > even worse.
> 
> I put my hand up to this one. I've found that I tend not to answer 
> requests because I know that Nick is likely to do it. This has two 
> explanations.
> 
> 1. I don't think we should be sending multiple, possibly contradictory 
> messages to new users. I would prefer a more consistent approach.
>
> 2. I don't think it is a good use of resources to duplicate the support 
> effort.

Both valid points, but are those considerations important enough that we
should be sacrificing turnaround times to meet them ?  Maybe they are.

> I would rather know that it is my $timeperiod to respond to support calls 
> and that I should be paying attention to the list. When $timeperiod is 
> over i would carry on with any open calls but someone else would take over 
> the new ones.

Having a single person follow each call through is nice for user
comfort, but not optimum for a quick turnaround.  IMO the speed at which
users get a satisfactory answer is the most important thing, as that is
what stops them giving up and using another (maybe less secure) script.

Many times, one of us has answered an initial query with a request for
further information, and another has answered the reply with the
solution.  This is a good thing IMO.

> As it is, it is all too easy for me to slack-off knowing that the calls
> will probably get answered by Nick. This isn't good but as you say, we all
> have other demands on our time. If you're going to answer the call anyway,
> why do I need to spend the time ?

Because you answering it now is better in terms of turnaround time than
me answering it later.

> In respect of escalations, I feel bad that when I had reached the end of 
> my knowledge there was no backup to help get the call resolved. Giving 
> explicit ownership to individuals helps to encourage that support. 
> Handled correctly with the user, they should understand that more help is 
> needed and the developer should actually have more time to help with such 
> things if they are not busy answering lots of other calls.

You're talking about the TFmail upload problem, right ?  I looked at that
(quite hard) but I couldn't think of anything that you hadn't already tried.
The escalation method of posting to nms-dev *didn't* let you down there - I
would have failed just the same had it been escalated to me via a fancy
ticketing system.

> > I don't like that.  Lurking on the dev list is a nice way to get into a
> > project, and I wouldn't like to see us close that door.
> > 
> > If this is meant to encourage people to join support groups, I would
> > have though it would be better to take commit privileges away from
> > those who won't.
> 
> I'm not sure that closing the dev list will help establish a community but 
> I do think there needs to be an invite-only list of people that drive the 
> development of the project.

We could do that with CC in email with our leader posting the outcome to
the dev list as a policy announcement, couldn't we ?

--
Nick

Re: [Nms-cgi-devel] nms project - moving forward

[Simon W. <es...@ou...>]

On Mon, 13 Jan 2003, Nick Cleaton wrote:

> On Sun, Jan 12, 2003 at 04:35:41PM +0000, Dave Cross wrote:
> >
> >   One of the things that is supposed to differentiate between us and Matt Wright
> >   is that we have a good support system. For some people that doesn't
> >   seem to be true currently.
> 
> Our current standard of support is less than perfect, but I hope you'll
> agree that it's a lot better than none at all, so it's still a big win
> over Matt's scripts.

Definitely but I think that Dave is right to consider how we organise the 
group to go forward in a sustainable fashion and to do it before it 
becomes really critical.

> >   There are enough of us that the support effort doesn't need to be very 
> >   onerous for a small number of people. If we spread it out, each of us
> >   would only need to deal with a very small number of emails.
> 
> Very true, it would be nice to see more people looking through the
> support list and answering any questions that they feel able to deal
> with.

[snip]

> > These groups will also be responsible within themselves for assign rotas
> > of people who will deal with support issues. These will designate a
> > "first line support" person. This person will be able to call on other
> > people within the group to help them solve problems that they can't work
> > out on their own.
> 
> That would be a good idea if we all did this 9 to 5, but given that we
> don't, internal escalations are really going to kill support turn around
> times.
> 
> Anything that moves away from the existing scheme (first person who
> both sees the question and knows the answer replies) is going to
> extend turnaround times as far as I can see.
> 
> If people are ignoring support requests to which they know the answer
> because they aren't in the right group then turn around times will be
> even worse.

I put my hand up to this one. I've found that I tend not to answer 
requests because I know that Nick is likely to do it. This has two 
explanations.

1. I don't think we should be sending multiple, possibly contradictory 
messages to new users. I would prefer a more consistent approach.

2. I don't think it is a good use of resources to duplicate the support 
effort.

I would rather know that it is my $timeperiod to respond to support calls 
and that I should be paying attention to the list. When $timeperiod is 
over i would carry on with any open calls but someone else would take over 
the new ones.

As it is, it is all too easy for me to slack-off knowing that the calls
will probably get answered by Nick. This isn't good but as you say, we all
have other demands on our time. If you're going to answer the call anyway,
why do I need to spend the time ? It's human nature but it is bad for the
long term development of the project.

In respect of escalations, I feel bad that when I had reached the end of 
my knowledge there was no backup to help get the call resolved. Giving 
explicit ownership to individuals helps to encourage that support. 
Handled correctly with the user, they should understand that more help is 
needed and the developer should actually have more time to help with such 
things if they are not busy answering lots of other calls.

> > I also intend to make the developers mailing list closed. So that only 
> > people who are in one of these support groups will be subscribed to the
> > list.
> 
> I don't like that.  Lurking on the dev list is a nice way to get into a
> project, and I wouldn't like to see us close that door.
> 
> If this is meant to encourage people to join support groups, I would
> have though it would be better to take commit privileges away from
> those who won't.

I'm not sure that closing the dev list will help establish a community but 
I do think there needs to be an invite-only list of people that drive the 
development of the project.

I think the creation of a support wiki (or other favoured collaboration 
tool) and the public acknowledgement of contributors and developers will 
do more towards that aim.

> The website changes sound good to me.

Me too, now where did I put that round tuit... ? :)

Simon.

Re: [Nms-cgi-devel] nms project - moving forward

[Olivier D. <dr...@sh...>]

On Mon, Jan 13, 2003 at 08:44:22PM +0000, Nick Cleaton wrote:
> Our current standard of support is less than perfect, but I hope you'll
> agree that it's a lot better than none at all, so it's still a big win
> over Matt's scripts.

I agree to this. Yes there are unanswered support requests. I used to
work in customer assistance and even with several people answering the
phone, we would sometimes get wait times of above 1h and people as you
would imagine would hang-up before they would even get answered.

But as Nick says, for a non-profit group of volunteers we're not in such
a bad situation.

> Any objections to the OO module based scheme I described in my
> previous post to nms-dev ?

I love it. It think it'll definetly go with NMS's philosophy to teach
better programming practices. It might also prove useful for code reuse
within the scripts or if we decided to create more script (ie. have more
user support request, yay!)

> Anything that moves away from the existing scheme (first person who
> both sees the question and knows the answer replies) is going to
> extend turnaround times as far as I can see.
> 
> If people are ignoring support requests to which they know the answer
> because they aren't in the right group then turn around times will be
> even worse.

I agree with that too. I think we just need to get a few people to at
least read the emails. Most of the requests aren't too hard to deal
with and most people with Perl knowledge who have read the README files
can answer them.

> I don't like that.  Lurking on the dev list is a nice way to get into a
> project, and I wouldn't like to see us close that door.
> 
> If this is meant to encourage people to join support groups, I would
> have though it would be better to take commit privileges away from
> those who won't.

Makes sense to me too. Lurking doesn't hurt anyone and doesn't make the
project worse. Removing commit privileges would probably help keep
control on who checks-in code and it is sound that only those who have
spent some time working with the script can commit.

-Olivier

-- 
                  __-/|    ? ?     |\-__
             __--/  /  \   (^^)   /  \  \--__
          _-/   /   /   \ / ( )  /   \   \   \-_
         /  /   /  /     ~(  ^^ ~     \  \   \  \
         / Oli Dragon    dr...@sh... \
        /  Sfwr Eng III  (  McMaster University  \
        /  /  /     __--_ (   ) __--__     \  \  \
        |  /  /  _/        \_ \_       \_  \  \  |
         \/  / _/            \_ \_       \_ \  \/
          \_/ /                -\_\        \ \_/
            \/                   -)         \/
                                *~
 ___--<******************************************************>--___
[http://pgp.mit.edu:11371/pks/lookup?search=olivier+dragon&op=index]
 ~~~--<******************************************************>--~~~

Re: [Nms-cgi-devel] nms project - moving forward

[Nick C. <ni...@cl...>]

On Sun, Jan 12, 2003 at 04:35:41PM +0000, Dave Cross wrote:
> Here are some thoughts about the nms project and its future. Thanks to
> Simon Wilcox for helping me thrash out some of the details. Please read
> all of this message.
> 
> The nms project is very successful. And I'm not convinced that we are
> properly geared up for that success. I don't want the project to be 
> forced to closed down, so I think we have to change the way we work.
> 
> I think we're having two major problems.
> 
> * Very small number of people involved in support.
> 
>   We have 65 people on the developers mailing list. But I think there
>   have been about five people who have answered a support question in
>   the last two months. I am, of course, eternally grateful to those 
>   people for the time they put it, but if we keep relying on a such
>   a small number of people they will come under more and more pressure
>   until they decide they can't be bothered any more and leave the 
>   project.
>
>   There are also a small (but growing, I think) number of support emails
>   that just don't get answered. This makes the project look bad.
>
>   One of the things that is supposed to differentiate between us and Matt Wright
>   is that we have a good support system. For some people that doesn't
>   seem to be true currently.

Our current standard of support is less than perfect, but I hope you'll
agree that it's a lot better than none at all, so it's still a big win
over Matt's scripts.

>   There are enough of us that the support effort doesn't need to be very 
>   onerous for a small number of people. If we spread it out, each of us
>   would only need to deal with a very small number of emails.

Very true, it would be nice to see more people looking through the
support list and answering any questions that they feel able to deal
with.

> * Very little development going on
> 
>   Nick Cleaton is doing great work on FormMail and TFMail, but they
>   seem to be the only programs that are moving forward. Once again I
>   have to wonder why we have 65 people on the development list if most
>   of them have no interest in doing any development.

Which way is forward ?

Any objections to the OO module based scheme I described in my
previous post to nms-dev ?

>   A few weeks ago, I posted several emails to the development list in
>   one afternoon. They were all ideas for improvements that came from
>   support requests. I posted them to the devel list hoping for a bit
>   of discussion about the suggestions followed by someone volunteering 
>   to take the project on. All of these emails were completely ignored.
> 
>   Simon also posted a number of emails to the devel list during 
>   December. This were also ignored (by me too, I'm sorry to admit).

I too have ignored the dev emails of others and had mine ignored in
turn.  Coming up with hairbrained schemes is so much more fun than
talking other people out of their hairbrained schemes, isn't it ?

>   As with support, if people make suggestions for improvements to our
>   scripts and they are just ignored, then it makes us look bad.
>
> Ok. So those are the problems. Here are some suggestions for solutions.
> 
> I need to delegate responsibility for the development and support for the
> scripts. Already Nick pretty much controls FormMail and TFMail, but we
> need to take that further.
> 
> I suggest that Nick gets a group of about four or five volunteers to help
> him develop and support FormMail and TFMail. This group will be 
> responsible for handling all support email on these scripts and for making
> new releases available.
> 
> We'll also create smaller groups that do the same for the other scripts.
> We'll probably need separate groups for wwwboard, search and guestbook as
> (after formmail) they are the most commonly used. The other scripts can
> probably all be dealt with by a single group.
>
> These groups will also be responsible within themselves for assign rotas
> of people who will deal with support issues. These will designate a
> "first line support" person. This person will be able to call on other
> people within the group to help them solve problems that they can't work
> out on their own.

That would be a good idea if we all did this 9 to 5, but given that we
don't, internal escalations are really going to kill support turn around
times.

Anything that moves away from the existing scheme (first person who
both sees the question and knows the answer replies) is going to
extend turnaround times as far as I can see.

If people are ignoring support requests to which they know the answer
because they aren't in the right group then turn around times will be
even worse.

> I also intend to make the developers mailing list closed. So that only 
> people who are in one of these support groups will be subscribed to the
> list.

I don't like that.  Lurking on the dev list is a nice way to get into a
project, and I wouldn't like to see us close that door.

If this is meant to encourage people to join support groups, I would
have though it would be better to take commit privileges away from
those who won't.

> In order to foster more of a feeling of responsibility towards the 
> scripts I'd like to introduce a "team bios" page on the web page so that
> people can see who's who on the project.
>
> And speaking of the web site, it needs an overhaul so I'd like to create
> another group that is responsible for that. Amongst the things I'd like 
> them to look at are:
> 
> * Team bios page
> 
> * Script documentation on the web site
>   (even better if it's auto-generated from the README files as a
>   script is released).
> 
> * Script demos on the web site
> 
> * More FAQs
>   Perhaps even some kind of "knowledge base" or wiki.
> 
> * Announcements
>   I'd like to encourage people to sign up to a new announcements list
>   when they download our scripts. They will then get automatic emails
>   when a new version is released. This announcements should also be 
>   listed on the web site.
> 
> * Articles
>   Useful articles for CGI beginners. Things like "idiots guide to 
>   debugging a CGI script".

The website changes sound good to me.

--
Nick

RE: [Nms-cgi-devel] nms project - moving forward

[Wizard <wi...@ne...>]

Ok, let me know if this is acceptable:

First, I have just downloaded wwwboard, and will have a look. I'll be busy
for the short-term with a few other projects, so I don't know how much I'll
get done, but as I proceed, you can expect questions/RFCs to this list.

A few things, partly because SourceForge is presently broken:

1.> It would be nice if anyone has an existing installation that they could
.tar.gz for me to test against. Nothing too huge, please.

2.> I would like to find out where we are putting this stuff. I couldn't
find a CVS/RCS reference on the web site, but I'm assuming that there is one
from the $Id tags. Some info please.

3.> It would be nice if someone could compile all of the Support requests
for WWWBoard into a list. SourceForge's Search system is presently broken
and I'm not subscribed to the list, so if you already have the list in your
mail,...

4.> We should try to recruit people to run QC tests, as I presently only
have Win2k/Apache, Solaris/Apache, and Linux/Apache available for testing.
Ideally it would be nice to have a nms-testers list, if that's possible.
Perhaps we could recruit some of the ISPs listed on pages for that.

If anyone else is planning any changes, please let me know and I'll hold off
or we can split up the project. From the version that I've downloaded, it
looks as though no one has done anything since last September, though.

Let me know if this is OK with everyone,
Grant M.



> -----Original Message-----
> From: nms...@li...
> [mailto:nms...@li...]On Behalf Of Dave
> Cross
> Sent: Sunday, January 12, 2003 11:36 AM
> To: nms...@li...
> Subject: [Nms-cgi-devel] nms project - moving forward
>
>
> Here are some thoughts about the nms project and its future. Thanks to
> Simon Wilcox for helping me thrash out some of the details. Please read
> all of this message.
>
> The nms project is very successful. And I'm not convinced that we are
> properly geared up for that success. I don't want the project to be
> forced to closed down, so I think we have to change the way we work.
>
> I think we're having two major problems.
>
> * Very small number of people involved in support.
>
>   We have 65 people on the developers mailing list. But I think there
>   have been about five people who have answered a support question in
>   the last two months. I am, of course, eternally grateful to those
>   people for the time they put it, but if we keep relying on a such
>   a small number of people they will come under more and more pressure
>   until they decide they can't be bothered any more and leave the
>   project.
>
>   There are also a small (but growing, I think) number of support emails
>   that just don't get answered. This makes the project look bad. One of
>   the things that is supposed to differentiate between us and Matt Wright
>   is that we have a good support system. For some people that doesn't
>   seem to be true currently.
>
>   There are enough of us that the support effort doesn't need to be very
>   onerous for a small number of people. If we spread it out, each of us
>   would only need to deal with a very small number of emails.
>
> * Very little development going on
>
>   Nick Cleaton is doing great work on FormMail and TFMail, but they
>   seem to be the only programs that are moving forward. Once again I
>   have to wonder why we have 65 people on the development list if most
>   of them have no interest in doing any development.
>
>   A few weeks ago, I posted several emails to the development list in
>   one afternoon. They were all ideas for improvements that came from
>   support requests. I posted them to the devel list hoping for a bit
>   of discussion about the suggestions followed by someone volunteering
>   to take the project on. All of these emails were completely ignored.
>
>   Simon also posted a number of emails to the devel list during
>   December. This were also ignored (by me too, I'm sorry to admit).
>
>   As with support, if people make suggestions for improvements to our
>   scripts and they are just ignored, then it makes us look bad.
>
>
> Ok. So those are the problems. Here are some suggestions for solutions.
>
> I need to delegate responsibility for the development and support for the
> scripts. Already Nick pretty much controls FormMail and TFMail, but we
> need to take that further.
>
> I suggest that Nick gets a group of about four or five volunteers to help
> him develop and support FormMail and TFMail. This group will be
> responsible for handling all support email on these scripts and for making
> new releases available.
>
> We'll also create smaller groups that do the same for the other scripts.
> We'll probably need separate groups for wwwboard, search and guestbook as
> (after formmail) they are the most commonly used. The other scripts can
> probably all be dealt with by a single group.
>
> These groups will also be responsible within themselves for assign rotas
> of people who will deal with support issues. These will designate a
> "first line support" person. This person will be able to call on other
> people within the group to help them solve problems that they can't work
> out on their own.
>
> I also intend to make the developers mailing list closed. So that only
> people who are in one of these support groups will be subscribed to the
> list.
>
> In order to foster more of a feeling of responsibility towards the
> scripts I'd like to introduce a "team bios" page on the web page so that
> people can see who's who on the project.
>
> And speaking of the web site, it needs an overhaul so I'd like to create
> another group that is responsible for that. Amongst the things I'd like
> them to look at are:
>
> * Team bios page
>
> * Script documentation on the web site
>   (even better if it's auto-generated from the README files as a
>   script is released).
>
> * Script demos on the web site
>
> * More FAQs
>   Perhaps even some kind of "knowledge base" or wiki.
>
> * Announcements
>   I'd like to encourage people to sign up to a new announcements list
>   when they download our scripts. They will then get automatic emails
>   when a new version is released. This announcements should also be
>   listed on the web site.
>
> * Articles
>   Useful articles for CGI beginners. Things like "idiots guide to
>   debugging a CGI script".
>
> Well, that's about all for now. Please let mw know what you think.
>
> I really think that if we don't do something soon, then the project is
> in danger of being overwhelmed.
>
> Thanks for listening,
>
> Dave...
>
> --
>   Drugs are just bad m'kay
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Nms-cgi-devel mailing list
> Nms...@li...
> https://lists.sourceforge.net/lists/listinfo/nms-cgi-devel
>

Re: [Nms-cgi-devel] nms project - moving forward

[Olivier D. <dr...@sh...>]

Hi Everyone,

I've been one of the quiet ones for a very long time, being very busy
with University and all. There are mainly two things I'd like to
mention:

1. I agree with these organizational measures to a certain extent.
   Giving a smaller group feeling might boost the willingness of
   developpers to put effort into it. It also allows developpers to get
   more familiar with one script. On the flip side I also have some
   issues with them. First this is an open source project to which
   people *volunteer* their own time to. This is one of the greatest
   thing about open source, but can also be it's pin in the foot. I
   don't think going about beating on people because they don't put
   enough effort into it is a good thing. You're more likely to scare
   people away then attract them. Second, the group thing might not work
   if one group ends up not having time to volunteer in which case some
   scripts will be left out of development and support (which I guess
   couldn't be that much worse than right now, but no better either).

2. I don't have much time to volunteer and don't want to "lead" any
   group. That said, if someone wants to step up to that I'll gladly
   look over simple search.

-Olivier

On Sun, Jan 12, 2003 at 04:35:41PM +0000, Dave Cross wrote:
> Here are some thoughts about the nms project and its future. Thanks to
> Simon Wilcox for helping me thrash out some of the details. Please read
> all of this message.
> 
> The nms project is very successful. And I'm not convinced that we are
> properly geared up for that success. I don't want the project to be 
> forced to closed down, so I think we have to change the way we work.
> 
> I think we're having two major problems.
> 
> * Very small number of people involved in support.
> 
>   We have 65 people on the developers mailing list. But I think there
>   have been about five people who have answered a support question in
>   the last two months. I am, of course, eternally grateful to those 
>   people for the time they put it, but if we keep relying on a such
>   a small number of people they will come under more and more pressure
>   until they decide they can't be bothered any more and leave the 
>   project.
> 
>   There are also a small (but growing, I think) number of support emails
>   that just don't get answered. This makes the project look bad. One of
>   the things that is supposed to differentiate between us and Matt Wright
>   is that we have a good support system. For some people that doesn't
>   seem to be true currently.
> 
>   There are enough of us that the support effort doesn't need to be very 
>   onerous for a small number of people. If we spread it out, each of us
>   would only need to deal with a very small number of emails.
> 
> * Very little development going on
> 
>   Nick Cleaton is doing great work on FormMail and TFMail, but they
>   seem to be the only programs that are moving forward. Once again I
>   have to wonder why we have 65 people on the development list if most
>   of them have no interest in doing any development.
> 
>   A few weeks ago, I posted several emails to the development list in
>   one afternoon. They were all ideas for improvements that came from
>   support requests. I posted them to the devel list hoping for a bit
>   of discussion about the suggestions followed by someone volunteering 
>   to take the project on. All of these emails were completely ignored.
> 
>   Simon also posted a number of emails to the devel list during 
>   December. This were also ignored (by me too, I'm sorry to admit).
> 
>   As with support, if people make suggestions for improvements to our
>   scripts and they are just ignored, then it makes us look bad.
> 
> 
> Ok. So those are the problems. Here are some suggestions for solutions.
> 
> I need to delegate responsibility for the development and support for the
> scripts. Already Nick pretty much controls FormMail and TFMail, but we
> need to take that further.
> 
> I suggest that Nick gets a group of about four or five volunteers to help
> him develop and support FormMail and TFMail. This group will be 
> responsible for handling all support email on these scripts and for making
> new releases available.
> 
> We'll also create smaller groups that do the same for the other scripts.
> We'll probably need separate groups for wwwboard, search and guestbook as
> (after formmail) they are the most commonly used. The other scripts can
> probably all be dealt with by a single group.
> 
> These groups will also be responsible within themselves for assign rotas
> of people who will deal with support issues. These will designate a
> "first line support" person. This person will be able to call on other
> people within the group to help them solve problems that they can't work
> out on their own.
> 
> I also intend to make the developers mailing list closed. So that only 
> people who are in one of these support groups will be subscribed to the
> list.
> 
> In order to foster more of a feeling of responsibility towards the 
> scripts I'd like to introduce a "team bios" page on the web page so that
> people can see who's who on the project.
> 
> And speaking of the web site, it needs an overhaul so I'd like to create
> another group that is responsible for that. Amongst the things I'd like 
> them to look at are:
> 
> * Team bios page
> 
> * Script documentation on the web site
>   (even better if it's auto-generated from the README files as a
>   script is released).
> 
> * Script demos on the web site
> 
> * More FAQs
>   Perhaps even some kind of "knowledge base" or wiki.
> 
> * Announcements
>   I'd like to encourage people to sign up to a new announcements list
>   when they download our scripts. They will then get automatic emails
>   when a new version is released. This announcements should also be 
>   listed on the web site.
> 
> * Articles
>   Useful articles for CGI beginners. Things like "idiots guide to 
>   debugging a CGI script".
> 
> Well, that's about all for now. Please let mw know what you think.
> 
> I really think that if we don't do something soon, then the project is
> in danger of being overwhelmed.
> 
> Thanks for listening,
> 
> Dave...
> 
> -- 
>   Drugs are just bad m'kay
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Nms-cgi-devel mailing list
> Nms...@li...
> https://lists.sourceforge.net/lists/listinfo/nms-cgi-devel

-- 
                  __-/|    ? ?     |\-__
             __--/  /  \   (^^)   /  \  \--__
          _-/   /   /   \ / ( )  /   \   \   \-_
         /  /   /  /     ~(  ^^ ~     \  \   \  \
         / Oli Dragon    dr...@sh... \
        /  Sfwr Eng III  (  McMaster University  \
        /  /  /     __--_ (   ) __--__     \  \  \
        |  /  /  _/        \_ \_       \_  \  \  |
         \/  / _/            \_ \_       \_ \  \/
          \_/ /                -\_\        \ \_/
            \/                   -)         \/
                                *~
 ___--<******************************************************>--___
[http://pgp.mit.edu:11371/pks/lookup?search=olivier+dragon&op=index]
 ~~~--<******************************************************>--~~~

Re: [Nms-cgi-devel] Re: ISP listing for nms formmail

[Nicholas C. <ni...@un...>]

On Sun, Jan 12, 2003 at 05:30:11PM -0000, David Simmons - EliteUKServe.Net wrote:
> yes and a lot of them looking at the logs set the agent as IE :)
> 
> .NET is a new one to appear now ... sigh

Gah. Do they fake IE well enough that one can't tell them from a real IE?
eg if the have the User-Agent spot on, do they have the accept headers right
for what IE typically accepts? There's not enough in common logfile formats
to answer that question, is there?

Maybe IE doesn't screw up on 400s. I don't have a machine capable of running
IE here, let alone a copy, so I can't test it.

Nicholas Clark

Re: [Nms-cgi-devel] Re: ISP listing for nms formmail

[David S. - EliteUKServe.N. <dav...@el...>]

yes and a lot of them looking at the logs set the agent as IE :)

.NET is a new one to appear now ... sigh


----- Original Message -----
From: Nicholas Clark <ni...@un...>
To: Dave Cross <da...@da...>
Cc: David Simmons - EliteUKServe.Net <dav...@el...>;
<nms...@li...>
Sent: Sunday, January 12, 2003 5:22 PM
Subject: Re: [Nms-cgi-devel] Re: ISP listing for nms formmail


> > On Tue, Dec 24, 2002 at 04:47:59PM +0000, David Simmons -
EliteUKServe.Net (dav...@el...) wrote:
> > >
> > > Hi,
> > >
> > > A suggestion:
> > >
> > > It would be nice to send a 400 type error to the screen when the
script
> > > rejects a user's/bot's post? Otherwise the scripts that these spammers
are
> > > using are still sending GETs & POSTs as they are getting a 200
returned. This
> > > obviously uses more of the ISP's and most likely customer's bandwidth
usage.
>
> I confess I'm only a lurker on the developers' list who hasn't even
> installed the NMS scripts, let alone developed on them, so I'm guessing
that
> the fail screen displays some sort of useful message to the user about why
> their message was rejected, and that this can be down to a genuine mistake
> that they have to fix. Presumably this page is currently sent as "200 OK"
>
> What happens on Microsoft Internet Explorer if you send this page out with
a
> 400 series error code? Does IE substitute one of its "helpful" error
pages?
> [eg the "maybe you typed the URL wrong" page, the one that is so
$expletive
> useful, as it comes up for DNS failure and file not found on the server]
>
> If so, this doesn't rule this idea out, but maybe it would have to be done
> based on user agent. Either by negative filtering (do it unless they say
> they're IE) or positive filtering (do it only if they provide a user agent
> and we know it's not IE)
>
> Do spambots typically set user agent strings?
>
> Nicholas Clark
>

Re: [Nms-cgi-devel] Re: ISP listing for nms formmail

[Nicholas C. <ni...@un...>]

> On Tue, Dec 24, 2002 at 04:47:59PM +0000, David Simmons - EliteUKServe.Net (dav...@el...) wrote:
> > 
> > Hi,
> > 
> > A suggestion:
> > 
> > It would be nice to send a 400 type error to the screen when the script 
> > rejects a user's/bot's post? Otherwise the scripts that these spammers are 
> > using are still sending GETs & POSTs as they are getting a 200 returned. This 
> > obviously uses more of the ISP's and most likely customer's bandwidth usage.

I confess I'm only a lurker on the developers' list who hasn't even
installed the NMS scripts, let alone developed on them, so I'm guessing that
the fail screen displays some sort of useful message to the user about why
their message was rejected, and that this can be down to a genuine mistake
that they have to fix. Presumably this page is currently sent as "200 OK"

What happens on Microsoft Internet Explorer if you send this page out with a
400 series error code? Does IE substitute one of its "helpful" error pages?
[eg the "maybe you typed the URL wrong" page, the one that is so $expletive
useful, as it comes up for DNS failure and file not found on the server]

If so, this doesn't rule this idea out, but maybe it would have to be done
based on user agent. Either by negative filtering (do it unless they say
they're IE) or positive filtering (do it only if they provide a user agent
and we know it's not IE)

Do spambots typically set user agent strings?

Nicholas Clark

Re: [Nms-cgi-devel] nms project - moving forward

[Nicholas C. <ni...@un...>]

On Sun, Jan 12, 2003 at 04:35:41PM +0000, Dave Cross wrote:

>   We have 65 people on the developers mailing list. But I think there
>   have been about five people who have answered a support question in
>   the last two months. I am, of course, eternally grateful to those 

> I also intend to make the developers mailing list closed. So that only 
> people who are in one of these support groups will be subscribed to the
> list.

Currently I'm subscribed to the developers' list. (Obviously, because I
have received and am replying to this message). I'm not aware of very
many people who have actually sent mail to this list, the proportion of
that 65 who are 100% lurkers seems quite high.

I'm very unlikely to join any of the support groups, as I don't have enough
CFT to do all the things I'm already doing, and it would be wrong to
volunteer to be part of a support group where I can't pull my weight. So
by implication of the above I would become unsubscribed from the development
list.

Avoid the special case, or exceptions are bad, m'kay.
And I can't see a way to say "hmm. non-lurkers on development are useful
and can stay subscribed"

I'm not sure if I'm actually adding anything useful to the development
process by semi-lurking on this list - development itself doesn't take place
as patches sent for code review to the list, hence there's not that much
whizzing by that I could comment on. Hence it's quite likely that the
development process won't lose anything by dropping anyone like me who does
actively read messages but doesn't actively develop or support.

I'm not sure if any of the other 60 odd people who are subscribed but never
e-mail would behave in the same way as I would for the developers list
becoming closed. I think NMS would reduce soureforge's outgoing mail traffic,
but I don't think it would gain any new support people. So I'm not convinced
what the benefit of closing the development list is.

Hopefully I'm wrong, and it would cause people to join the support teams,
but the silent majority here do seem to be silent, and have been over
recorded history, so I suspect they'd continue to be silent on support
lists.

Hello silent majority. :-) Hello echelon :-)

Khaddafi AK-47 Soviet Mena Uzi Area 51 North Korea Vickie Weaver Ron
Brown Croatian Vince Foster Craig Livingstone $400 million in gold
bullion genetic Watergate

Nicholas Clark

Re: [Nms-cgi-devel] Re: ISP listing for nms formmail

[Dan K. <da...@ke...>]

OK, this is kind of off-topic, but here's a related idea for SMTP:
http://www.deadly.org/article.php3?sid=20021220021332
describes a nifty approach -- when mail comes in from
a known open relay, a special mail daemon handles
it by reporting temporary failure.  This leaves the mail on the open relay's
outgoing queue, eventually disabling the open relay!
This is wonderful -- without any nasty behavior, it would
eventually either plug all the open relays or force
their sysadmins to fix them.

Dave Cross wrote:
> Thanks for the suggestion. I've forwarded it to the nms developers 
> mailing list for discussion.
> 
> nms developers - anyone got any comments on this suggestion?
> 
> On Tue, Dec 24, 2002 at 04:47:59PM +0000, David Simmons - EliteUKServe.Net (dav...@el...) wrote:
>>
>>It would be nice to send a 400 type error to the screen when the script 
>>rejects a user's/bot's post? Otherwise the scripts that these spammers are 
>>using are still sending GETs & POSTs as they are getting a 200 returned. This 
>>obviously uses more of the ISP's and most likely customer's bandwidth usage.
>>
>>This is by no means a critiscism but merely a suggestion.


-- 
Dan Kegel
Linux User #78045
http://www.kegel.com

[Nms-cgi-devel] nms project - moving forward

[Dave C. <da...@da...>]

Here are some thoughts about the nms project and its future. Thanks to
Simon Wilcox for helping me thrash out some of the details. Please read
all of this message.

The nms project is very successful. And I'm not convinced that we are
properly geared up for that success. I don't want the project to be 
forced to closed down, so I think we have to change the way we work.

I think we're having two major problems.

* Very small number of people involved in support.

  We have 65 people on the developers mailing list. But I think there
  have been about five people who have answered a support question in
  the last two months. I am, of course, eternally grateful to those 
  people for the time they put it, but if we keep relying on a such
  a small number of people they will come under more and more pressure
  until they decide they can't be bothered any more and leave the 
  project.

  There are also a small (but growing, I think) number of support emails
  that just don't get answered. This makes the project look bad. One of
  the things that is supposed to differentiate between us and Matt Wright
  is that we have a good support system. For some people that doesn't
  seem to be true currently.

  There are enough of us that the support effort doesn't need to be very 
  onerous for a small number of people. If we spread it out, each of us
  would only need to deal with a very small number of emails.

* Very little development going on

  Nick Cleaton is doing great work on FormMail and TFMail, but they
  seem to be the only programs that are moving forward. Once again I
  have to wonder why we have 65 people on the development list if most
  of them have no interest in doing any development.

  A few weeks ago, I posted several emails to the development list in
  one afternoon. They were all ideas for improvements that came from
  support requests. I posted them to the devel list hoping for a bit
  of discussion about the suggestions followed by someone volunteering 
  to take the project on. All of these emails were completely ignored.

  Simon also posted a number of emails to the devel list during 
  December. This were also ignored (by me too, I'm sorry to admit).

  As with support, if people make suggestions for improvements to our
  scripts and they are just ignored, then it makes us look bad.


Ok. So those are the problems. Here are some suggestions for solutions.

I need to delegate responsibility for the development and support for the
scripts. Already Nick pretty much controls FormMail and TFMail, but we
need to take that further.

I suggest that Nick gets a group of about four or five volunteers to help
him develop and support FormMail and TFMail. This group will be 
responsible for handling all support email on these scripts and for making
new releases available.

We'll also create smaller groups that do the same for the other scripts.
We'll probably need separate groups for wwwboard, search and guestbook as
(after formmail) they are the most commonly used. The other scripts can
probably all be dealt with by a single group.

These groups will also be responsible within themselves for assign rotas
of people who will deal with support issues. These will designate a
"first line support" person. This person will be able to call on other
people within the group to help them solve problems that they can't work
out on their own.

I also intend to make the developers mailing list closed. So that only 
people who are in one of these support groups will be subscribed to the
list.

In order to foster more of a feeling of responsibility towards the 
scripts I'd like to introduce a "team bios" page on the web page so that
people can see who's who on the project.

And speaking of the web site, it needs an overhaul so I'd like to create
another group that is responsible for that. Amongst the things I'd like 
them to look at are:

* Team bios page

* Script documentation on the web site
  (even better if it's auto-generated from the README files as a
  script is released).

* Script demos on the web site

* More FAQs
  Perhaps even some kind of "knowledge base" or wiki.

* Announcements
  I'd like to encourage people to sign up to a new announcements list
  when they download our scripts. They will then get automatic emails
  when a new version is released. This announcements should also be 
  listed on the web site.

* Articles
  Useful articles for CGI beginners. Things like "idiots guide to 
  debugging a CGI script".

Well, that's about all for now. Please let mw know what you think.

I really think that if we don't do something soon, then the project is
in danger of being overwhelmed.

Thanks for listening,

Dave...

-- 
  Drugs are just bad m'kay

[Nms-cgi-devel] Re: # $Id: FormMail.pl,v 2.20 2002/11/21 06:39:42 nickjc Exp $

[Dave C. <da...@da...>]

Anthony,

Thanks for your email. I've forwarded it to the developers' mailing list
so that someone can apply your fix to our code.

Dave...

On Sat, Jan 04, 2003 at 07:05:13PM -0000, Anthony Pringle (apr...@ch...) wrote:
> Hi Dave
> 
> I've been using your FormMail script for some time, yesterday I
> downloaded and installed the latest version. I also enabled the
> $wrap_text = 1 and $wrap_style = 1 to indent my messages.
> 
> I found that the script indented the message by the length of the
> "field name" but wasn't adding the extra two characters to make the
> line-up complete. Not knowing anything about Perl, I studied a couple
> of online tutorials - made an inspired guess - then modified a line in
> your code from
> 
> $subs_indent = ' ' x length($field_name);
> 
> to
> 
> $subs_indent = ' ' x (length($field_name) + 2);
> 
> Now it seems to work properly and I feel extraordinarily pleased with
> myself :-), so I thought I'd let you know.
> 
> Regards
> 
> Anthony Pringle
> 
> 
> $wrap_style         - If $wrap_text is set to 1 then if this is set to
> 1 then
>                       the text will be wrapped in such a way that the
> left
>                       margin of the text is lined up with the
> beginning of the
>                       text after the description of the field - that
> is to
>                       say it is indented by the length of the field
> name
>                       plus 2.  If it is set to 2 then the subsequent
> lines
>                       of the text will not be indented at all and will
> be
>                       flush with the start of the lines.  The choice
> of style
>                       is really a matter of taste although you might
> find
>                       that style 1 does not work particularly well if
> your
>                       e-mail client uses a proportional font where the
> spaces
>                       of the indent might be smaller than the
> characters in
>                       the field name.
> 

-- 
  It was long ago and it was far away
  And it was so much better that it is today

[Nms-cgi-devel] Re: ISP listing for nms formmail

[Dave C. <da...@da...>]

David,

Thanks for the suggestion. I've forwarded it to the nms developers 
mailing list for discussion.

nms developers - anyone got any comments on this suggestion?

Dave...

On Tue, Dec 24, 2002 at 04:47:59PM +0000, David Simmons - EliteUKServe.Net (dav...@el...) wrote:
> 
> Hi,
> 
> A suggestion:
> 
> It would be nice to send a 400 type error to the screen when the script 
> rejects a user's/bot's post? Otherwise the scripts that these spammers are 
> using are still sending GETs & POSTs as they are getting a 200 returned. This 
> obviously uses more of the ISP's and most likely customer's bandwidth usage.
> 
> This is by no means a critiscism but merely a suggestion.
> 
> Kindest Regards
> 
> On Tuesday 24 December 2002 16:43, David Simmons - EliteUKServe.Net wrote:
> > Hi,
> >
> > We have now replaced all versions of shoddy matt's formmail with your
> > version.
> >
> > Kindest Regards,
> 
> -- 
> 
> David Simmons
> EliteUKServe.Net
> 
> EMail: dav...@el...
> Tel*: 0871 872 4262
> _____________________________________________________________________
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. EliteUKServe.Net do not accept legal responsibility
> for the contents of this message. Any views or opinions presented are
> solely those of the author and do not necessarily represent those of
> EliteUKServe.Net. This message can not be classed as SPAM, the
> recipient has not been added to any mailing lists.
> 
> http://eliteukserve.net
> _____________________________________________________________________
> * 0871 calls are charged at 10ppm
> 
> 

-- 
  Love is a fire of flaming brandy
  Upon a crepe suzette

Re: [Nms-cgi-devel] Reworked FormMail

[Dan M. <oma...@lc...>]

>Of course, we'll need a release time script to build a standalone
>version of FormMail.pl with all those modules inlined into it before
>we can consider making releases

It would be great to have a modularized package publicly available as
well.

Many of the users of FormMail.pl are in fact ISPs setting up the
scripts
for use by their customers.  Upgrades would be more likely if  the
process
was updating a library instead of 100s of cgi-bin directories...

For what it is worth, I am happily looking forward to seeing V2 in
anonymous CVS

----- Original Message -----
From: "Nick Cleaton" <ni...@cl...>
To: <nms...@li...>
Sent: Saturday, January 04, 2003 3:36 AM
Subject: [Nms-cgi-devel] Reworked FormMail


>
> While I was on holiday, I couldn't resist pulling FormMail.pl apart
and
> trying to make it better.
>
>
> Highlights:
>
>   * All the code is in modules
>
>   * All OO - bits shared with other scripts are in a superclass
>
>   * User customisation mechanism via inheritance - no more support
>     posts like "change X to Y on line 804", now we can just say
>     "add this code to the user customisation section of your
FormMail.pl"
>     instead.
>
>   * Trace information is in a Received header, which may or may not
>     be an improvement.
>
>   * The values of the configuration form fields can be fixed in the
>     script config, if desired.
>
>
> So FormMail.pl can now be trimmed down to:
>
>
> : #!/usr/bin/perl -wT
> : use strict;
> : use vars qw(
> :   $DEBUGGING $emulate_matts_code $secure
> :   $allow_empty_ref $max_recipients $mailprog @referers
> :   @allow_mail_to @recipients %recipient_alias
> :   @valid_ENV $date_fmt $style $send_confirmation_mail
> :   $confirmation_text $locale $charset $no_content
> :   $double_spacing $wrap_text $wrap_style $postmaster
> : );
> :
> : # PROGRAM INFORMATION
> : # -------------------
> : # FormMail.pl $Revision: 2.20 $
> : #
> : # This program is licensed in the same way as Perl
> : # itself. You are free to choose between the GNU Public
> : # License <http://www.gnu.org/licenses/gpl.html>  or
> : # the Artistic License
> : # <http://www.perl.com/pub/a/language/misc/Artistic.html>
> : #
> : # For help on configuration or installation see the
> : # README file or the POD documentation at the end of
> : # this file.
> :
> : # USER CONFIGURATION SECTION
> : # --------------------------
> : # Modify these to your own settings. You might have to
> : # contact your system administrator if you do not run
> : # your own web server. If the purpose of these
> : # parameters seems unclear, please see the README file.
> : #
> : BEGIN
> : {
> :   $DEBUGGING         = 1;
> :   $emulate_matts_code= 0;
> :   $secure            = 1;
> :   $allow_empty_ref   = 1;
> :   $max_recipients    = 5;
> :   $mailprog          = '/usr/lib/sendmail -oi -t';
> :   $postmaster        = '';
> :   @referers          = qw(dave.org.uk 209.207.222.64 localhost);
> :   @allow_mail_to     = qw(yo...@yo...main
som...@yo...main localhost);
> :   @recipients        = ();
> :   %recipient_alias   = ();
> :   @valid_ENV         = qw(REMOTE_HOST REMOTE_ADDR REMOTE_USER
HTTP_USER_AGENT);
> :   $locale            = '';
> :   $charset           = 'iso-8859-1';
> :   $date_fmt          = '%A, %B %d, %Y at %H:%M:%S';
> :   $style             = '/css/nms.css';
> :   $no_content        = 0;
> :   $double_spacing    = 1;
> :   $wrap_text         = 0;
> :   $wrap_style        = 1;
> :   $send_confirmation_mail = 0;
> :   $confirmation_text = <<'END_OF_CONFIRMATION';
> : From: yo...@yo...
> : Subject: form submission
> :
> : Thank you for your form submission.
> :
> : END_OF_CONFIRMATION
> : #
> : # USER CONFIGURATION << END >>
> : # ----------------------------
> : }
> : # USER CUSTOMISATION SECTION
> : # --------------------------
> : # Place custom code below.  This should be considered an expert
> : # feature.
> :
> :
> :
> : # USER CUSTOMISATION << END >>
> : # ----------------------------
> : # (no user serviceable parts beyond here)
> :
> : use CGI::NMS::Script::FormMail;
> : use base qw(CGI::NMS::Script::FormMail);
> :
> : use vars qw($script);
> : BEGIN {
> :   $script = __PACKAGE__->new(
> :      DEBUGGING              => $DEBUGGING,
> :      emulate_matts_code     => $emulate_matts_code,
> :      secure                 => $secure,
> :      allow_empty_ref        => $allow_empty_ref,
> :      max_recipients         => $max_recipients,
> :      mailprog               => $mailprog,
> :      postmaster             => $postmaster,
> :      referers               => [@referers],
> :      allow_mail_to          => [@allow_mail_to],
> :      recipients             => [@recipients],
> :      recipient_alias        => {%recipient_alias},
> :      valid_ENV              => [@valid_ENV],
> :      charset                => $charset,
> :      date_fmt               => $date_fmt,
> :      style                  => $style,
> :      no_content             => $no_content,
> :      double_spacing         => $double_spacing,
> :      wrap_text              => $wrap_text,
> :      wrap_style             => $wrap_style,
> :      send_confirmation_mail => $send_confirmation_mail,
> :      confirmation_text      => $confirmation_text,
> :   );
> : }
> :
> : $script->request;
> :
>
> ... and I have working implementations of the modules behind that:
>
>   http://cleaton.net/tmp/CGI/NMS/Script/FormMail.pm
>   http://cleaton.net/tmp/CGI/NMS/Script.pm
>   http://cleaton.net/tmp/CGI/NMS/Validator.pm
>   http://cleaton.net/tmp/CGI/NMS/Charset.pm
>   http://cleaton.net/tmp/CGI/NMS/Mailer.pm
>   http://cleaton.net/tmp/CGI/NMS/Mailer/Sendmail.pm
>   http://cleaton.net/tmp/CGI/NMS/Mailer/SMTP.pm
>
> ... those pass all current FormMail tests, although some test
scripts
> needed some munging before they'd work and it errs more on the side
> of security than it used to in the case where $secure is 0.
>
> I haven't put those in CVS yet, because I'm not sure where they
should
> go.  This is a big change, how about starting a new source namespace
> for it ?  The old one is a bit chaotic (mostly my fault) so I
suggest
> adding a /v2 directory for a version 2 of NMS, and checking in those
> .pm files under a /v2/lib/ directory.
>
> Of course, we'll need a release time script to build a standalone
> version of FormMail.pl with all those modules inlined into it before
> we can consider making releases from these sources.
>
> --
> Nick
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Nms-cgi-devel mailing list
> Nms...@li...
> https://lists.sourceforge.net/lists/listinfo/nms-cgi-devel
>