First of all, I would like to thank Jose-Maria for proposing this
alternative plan, and to invite anybody who has a new idea to do the
same. However, and I hope you will not take this as a negative comment,
private notes telling me that "This plan is likely to decrease the level
of service provided to the users" and "There is probably a better
solution" are not of much help. I am perfectly aware of the fact that my
proposed plan is not ideal and that, from a purely technical point of
view, it is obviously undesirable. There are a lot of other things, which
are undesirable from a purely technical point of view, and which are
still going to get done; good examples are IBM's OCO policy, the new
"improved" VMFBETTER tools, the use of X.400 which doesn't remove
trailing blanks from a message (least of all compress runs of identical
characters), etc. If you think there is a better solution, please propose
one and let's discuss it - just stating your belief will not help us make
progress.
Let's get back to Jose-Maria's alternate plan (let's call it plan #2).
First, as it was written it is not acceptable to me, as it would mean
that I would be accepting money from EARN in exchange for (some form of)
LISTSERV maintenance, which is something that I have never accepted and
do not plan to accept in the future. However, let's study plan 2 from the
technical point of view - maybe it can be further improved to meet my
goals.
I know of only two persons who can claim to be "LISTSERV specialists" (ie
people able to answer questions without having to look at the code) in
this network: Jose-Maria and myself. Jose-Maria has about 75% of my
LISTSERV-related knowledge, and if I had had to leave the network, I
would have liked to hand LISTSERV over to him. Unfortunately, none of
these two persons are willing to work for EARN, so let's move one step
downwards.
I can think of 3 EARN guys who have enough knowledge of LISTSERV to
answer some questions without looking at the code, and to know where to
look to answer the others. Although I can't speak for them, I know that
they have both a full-time job, so that they could only work part-time
for EARN (assuming they were interested of course). That might be enough
to answer questions, but they would need more time to do the actual
maintenance and/or development in case I stopped doing it, so that they
could not be considered as a serious "backup" solution; in other words,
EARN would not be guaranteeing the continuity of the maintenance (at
least not that of a serious maintenance), and the goal wouldn't be met
(unless several such persons worked on the code, but synchronizing 2-3
people working 25% of their time on something is not going to be very
easy).
If you move one step downwards again, you have a large number of people
who are competent and experienced enough to do this job, but not at 25%.
During the first N months (N=6?), these people would need to look at the
code to answer most questions, and quite often they wouldn't know where
to start looking at. That basically means they would forward the
questions to me and I would have to answer them, which won't reduce the
load in my mailbox (again, for the first N months). Since they would not
be writing any code (unless I misunderstood what Jose-Maria said), their
job would be quite boring: getting experience on someone else's software
to answer user questions, or, in other words, playing Help Desk. Besides,
I doubt they could really be relied on in case of problems: someone whose
knowledge is purely theorical usually has a lot of problems when he is
faced with a real life situation (try learning a truck driver's manual by
heart and then experimenting on the "real hardware" :-) ).
If you want a dependable "backup LISTSERV maintenance staff", you need
people who not only read the sources and answer questions, but also do
some programming (related to the thing they are learning, of course).
This should not be school-like "exercises" which are going to be checked
by a teacher and subsequently forwarded to the wastebasket, but real,
useful software that people are going to use and to provide feedback
about. That is the only way to learn, at least that's my personal
experience of learning.
To refine this plan, we have to take that into account, along with the
fact that I would not accept that an EARN employee did part of the
maintenance and development of the code I am working on, while I did the
other part (I think the reasons should be pretty clear to anyone who has
ever tried to work in an uncoordinated team with someone he didn't choose
to work with and who, apart from having a different opinions on almost
anything that needs to be done, is paid by an entity whose goals are
different from yours). That would probably create more conflicts than
there are today, and would catastrophically degrade the quality of the
software.
Any comment?
Eric
|
