response 59 of 92:

Oct 11 03:20 UTC 2006

re #45, 48

I made that identical suggestion almost a year ago (item 294 #86)

Maybe they'll listen to you. But it seems to be that the old guard of 
grex has a way of doing things and they aren't about to change anytime 
soon.

response 61 of 92:

Oct 11 04:43 UTC 2006

re 57
It's almost worse than that.  When some people start up discussions, some
other people seem to find it necessary to tell them to shut up.  I'm not going
to name names here, but...

If this is a system where we have to discuss to change something, and yet
those very discussions are discouraged, we're not getting very far.

response 63 of 92:

Oct 11 18:39 UTC 2006

resp:57 Yes, it is clear that the old way where staff did everything by
consensus isnt working anymore. That worked well when everyone knew each
other personally and communicated in social situations. I dont know what
the answer is now. The truth is that if you and some people whom you
talk to frequently wanted to start a similar system, you probably could
and it would probably be pretty nice. But what if you stayed and put
that energy into running *this* system? It seems to me that for the
effort and expense that would be put into a whole new system, the same
effort could be put into running things here. Run for board. Join staff
again. There are so few members here these days that the character of
this place can easily be what anyone wants to make it. I got on the
board last time with under 20 votes. 

resp:58 Why havent those things been tried? Because actually doing
something takes a lot more effort than sitting on the sidelines coming
up with great ideas. Both documentation and mentoring are good ideas and
both things involve someone's time and labor. 

response 65 of 92:

Oct 11 21:36 UTC 2006

Regarding #63; I was on staff.  It seemed like a waste of time.  But why?
Let me tell you by asking a question.

What, exactly, is someone supposed to DO on staff if everything they propose
to do (or actually DO do) is undone by other staff members who feel entitled
to dictate technical policy?  Here's an example: a couple of years ago, I
changed the symbolic link that points the ``bbs'' command to Picospan and
pointed it to fronttalk.  I think a total of two people noticed, since they
have problems with their .cfonce files.  Steve changed it back, and said in
BBS not to make major changes to grex without getting approval, or something
like that - the gist of it was that it had to be discussed and a concensus
arrived at.  (This was either in staff email or the staff conference; I
don't recall which, but think it was the conference.)  Basically, don't do
it again.  So much for initiative; my rationale was that we could have
identified the major bugs and rough points rather quickly with a larger
testing base and then fixed them, clearly the way to get rid of picospan.
Oh well.

As another example, consider my recent changes to move to the standard
password hashing algorithm: I've got the code written; it seems to work
(I've tested it on a throw-away test system at home).  But, EVEN IF I WERE
ON STAFF, putting it into the system would be like pulling teeth.  Why?
Because the old hash algorithm was somebody's baby (never mind that that
somebody logs into grex irregularly at best - like, once a year or so).
It's the same thing with replacing newuser, or replacing PicoSpan (which has
definite identifiable bugs that we can't fix because we don't have the
source code).

Then there's grexsoft: I put effort into re-writing a bunch of grex's
home-grown utilities when I was on staff.  I think some of them were much
improved (a lot of bugs were fixed).  However, no one reinstalled them after
the last system upgrade, despite my repeated requests, instructions how, and
offers for assistance.  It certainly takes away the motivation for helping
out.  Yeah, we *could*, as a community, put energy into fixing fronttalk to
the point where it was a viable alternative to picospan for everyone who
uses BBS regularly (I've used it as my standard BBS program for years; I
know of only one major bug that's probably a one-line fix).  But again, it's
somebody's baby, and even if we did that, there would be strong oposition
from the old guard to ditching the ancient program that is holding the
system back.  What's the point of doing the work if it's just going to be
ignored in the collective dust bin of grex's bit bucket?

These aren't examples of sitting on the sidelines sniping, they're actually
doing things.  But if none of it ever gets put into production, what's the
point?  If every not-even-major system change has to be funneled through
Steve et al, and they just doesn't want to change things, then what is
bringing in new staff members going to do, other than put more spin cycles
on the CPU with people who sit around cleaning up after disk hogs or zapping
spam accounts, and never doing anything FUN or INTERESTING?  If we want
janitors to take the load of Steve so he can do all the interesting work,
then just say that.  But if not, then more needs to change than just adding
a few people to a couple of Unix groups and mailing lists.

And I asked for opinions about me rejoining staff to work on grexsoft and
other basic system stuff; largely with the aim of making grex more
``standard.''  So far, I haven't heard much back about it (I'm certainly not
going to get on my knees and beg).  Slynne, I think you might have been one
of the few people to even acknowledge it.

response 67 of 92:

Oct 11 21:55 UTC 2006

Cross brings up a good point related to my documentation suggestion. I'm not
a techie, but if I understand the situation correctly, the more closely grex
can be brought to commonly accepted and understood standards, the less a
problem documentation becomes, because we don't have as much "customized" work
to track. Correct me if I'm wrong on this.

response 69 of 92:

Oct 11 22:21 UTC 2006

I have enough experience working with highly customized systems at my
job to know that there is a lot of value in moving closer to what is
standard.  

response 71 of 92:

Oct 13 15:30 UTC 2006

Re #58:  The CVS-based documentation mechanism was set up by Jan Wolter, 
as Dan mentioned in #47.  It's called "grexdoc" and is publicly 
accessible.  See the directory /a/r/e/remmers/grexdoc for a current 
copy.  In it you'll find instructions for downloading and installing the 
operating system, installing our various specialized applications such 
as party and backtalk, and many other things.  It's really quite 
complete, and the installation of major subsystems is automated via 
scripts.  Using grexedoc, I was able to bring up a "test" version of 
Grex on one of my own machines as part of our OS upgrade, modifying the 
documentation as needed to be consistent with OpenBSD 3.8, before the 
upgrade was applied to the "real" Grex.

Grexdoc is a very useful tool.  If there's been a problem with it, it's 
that not all staff members have been equally diligent in updating the 
CVS when they tweak the system, causing the documentation to be out of 
sync with reality here and there.  While this is not ideal, it's also a 
human failing that's hardly unique to Grex, as Lynne pointed out 
earlier.  But it's not fatal either -- it means that before doing the 
next OS upgrade, we'll have to take care of any loose ends and make sure 
that grexdoc is up to date.

response 73 of 92:

Oct 13 19:17 UTC 2006

Great, so my suggestion is far more doable than lynne was suggesting. Now get
on the personnel redundancy issue.

response 75 of 92:

Oct 14 00:08 UTC 2006

re 65

And now Fronttalk is basically in the same situation as Picospan, except with
more bugs.  The real question is whether janc would've put more work into it
if he noticed that it was GreX's primary BBS software, or if we would've wound
up using an almost unsupported program with more bugs and fewer options.

response 77 of 92:

Oct 14 02:26 UTC 2006

Re #74: And where did I ever say you thought it wasn't doable? Your exact 
words were "pain in the neck." And your "sideline" comment was a small 
aside in the discussion, so let's not try to rewrite history. 

The fact is there ARE volunteers who are not on the sidelines, and the 
board has no policy to maximize their value to grex. Try focusing on what 
you can do as a board member, rather then responding with 
characterizations of those who are not on the board or staff as doing 
less.

response 79 of 92:

Oct 14 02:48 UTC 2006

resp:77 Indeed. It is much easier to sit on the sidelines with
"brilliant" ideas complaining that others arent doing the work to
implement them. And that work *is* a pain in the neck sometimes. That
doesnt mean it isnt doable. It does make the work somewhat less likely
to get done. 

resp:78 I think that comes down to something the board certainly should
talk about. In the past, staff decisions (as far as I know) were reached
by some consensus. That worked well when the staff communicated with
each other better. But now, as far as I can tell, that doesnt seem to be
happening. So I think we probably should discuss how decisions about
technical issues are made. 

response 81 of 92:

Oct 14 03:22 UTC 2006

Really? Are you volunteering? Because if you are, that changes things.
What would you like to do? Perhaps you would be willing to coordinate a
project like organizing our documentation or setting up a mentoring
program?

response 83 of 92:

Oct 14 04:35 UTC 2006

I would volunteer to work on some pet projects.