|
|
|
Grex Board Meeting Minutes - April 1, 2007
Present: S. Lynne Fremont (slynne) - Board Member, President
Jan Wolter (janc) - Board Member, Secretary - Staff
Mark Conger (aruba) - Board Member, Treasurer
Collen McGee (cmcgee) - Board Member
Larry Kestenbaum (polygon) - Board Member
STeve Andre (steve) - Staff
Joe Gelinas (gelinas) - Staff
John Remmers (remmers)
Mary Remmers (mary)
Joe Smutter
Telepresent:
Dan Cross (cross) - Board Member
Bruce Howard (bhoward) - Board Member - Staff
Opening Gavel Tap: 7:23 pm
Meeting started late because of problems with the phone connection (Dan
was calling from a taxi, and kept losing his connection and taking Bruce
with him) and because Lynne was delayed.
Treasurer's Report:
Grex had a very good month in March, taking in $677 and spending only
$164. This is especially nice since April through September have
traditionally months with lower contributions, and it's nice to be in
good shape going in our annual slump.
Grex's bank balance is at a record high, nearly $7000. We are in very
good shape for possibly spending some money on system upgrades.
The IRS sent Grex a 990 tax form. We are not actually required to fill
this out, because our income is below the threshold for filing. Mark's
understanding is that if the IRS sends you a form, then you are required
to fill it out. Jan doubts this strongly, being of the opinion that the
IRS sends you forms when they think you need to fill them out, but that
the IRS is frequently mistaken.
Staff Report:
Since Dan and Bruce were out of touch during the staff report due to
phone problems, it was decided to postpone the staff report till later.
Old Business:
Upgrades to Grex
Particularly in the light of the fact that we have some money in the
bank, we wanted to consider what would be sensible upgrades to our
systems. Topics dicussed included:
SPAM FILTERING
There are devices/services that you can buy/subscribe to that
are supposed to get you good spam filtering. Staff was not
inclined to think such options would be either too expensive
or ineffective.
STeve felt we should implement grey-listing on Grex. Software
for this exists for OpenBSD. Basically, email from suspicious
hosts (ie, most hosts) is not blocked, but delayed, so that
the machine sending it has to spend more time sending it. High
performance spam delivery software generally won't bother. Since
it's mission is to deliver as much mail to as many people as
possible in the shortest time, it will just give up on delivering
to slow places, and skip on to someplace faster. Other sites
using this approach have seen very impressive reductions in spam,
and it is quite easy to implement. Obviously it won't stop
spammers with stupid crappy spam software, though it does slow
them down, making the deliver less spam, and making the world
a better place overall. And it is not a permanent fix, since
once lots of sites start doing this, spammers will have to bite
the bullet and start delivering to slow sites anyway.
Staff will work on implementing greylisting on Grex.
NEW MOTHERBOARD/MEMORY
We could upgrade Grex's motherboard and/or it's memory (we'd like
to have error correcting memory). We actually have plent of idle
CPU now, and aren't hurting for more CPU power or memory. However,
having more could enable us to do better spam filtering. A new
motherboard should be one that supports a remote console, so that
the system can be more easily maintained without having to
physically visit the computer.
Staff will research specific proposals to do this.
RAID DISKS/BIGGER DISKS
We would really like to move Grex to a more reliable disk system,
using some form of RAID. We would probably also substantially
increase the amount of disk we have at the same time. There
are various different versions of this, some that look to the
computer just like a plain disk, others that allow the computer
to monitor and control the RAID array in more sophisticated
ways.
Staff will research specific proposals to do this.
Internet Access Policy
Mark raised a question about our policy for Internet access for
various classes of users. Originally new users immediately got
quite a bit of net access, including among others:
- Full use of email, incoming and outgoing, local and external
- Full use of http, via lynx-like clients
- DNS access
There have been many abuses of this, in which people used Grex to
send spam, or use the http and/or DNS access to attack other hosts.
Some of these attacks were fierce enough to cause major problems for
the company that hosts Grex's computer. Allowing them to continue
would probably have meant we had to find a new home for Grex. Staff
therefore changed the rules so that new users could not send email
off of Grex, and could not use the Internet from Grex at all. The
plan was to institute a procedure by which these capabilities could
be granted to users by request, however, this procedure has never
been fully implemented. There are even some members that don't have
outbound access (those specific users have since been fixed).
Mark wanted to clarify what our policy was on this, so that staff
could finish implementing the tools for promoting users to the
net access class. This triggered a very long discussion of
alternative access structures. The board had some ideas that were
generally approved of, but did not put them to a vote, feeling that
such sweeping changes should be discussed first by the users and
might actually conflict with previous user votes, meaning they could
be instituted only by a user vote. So the board voted on a
simpler motion, that only clarified the user authentication rules
a bit. The desire to do something more sweeping is definately
still present.
The motion ultimately voted on was made by Larry and seconded by
Colleen:
A social validation process should be instituted so newusers
can be moved from the new limited status to the old much
less limited status which includes outgoing mail and all the
protocols allowed previously to unvalidated members.
This was unanimously approved.
"Social validation" here means the user wanting to be promoted sends
email to a group of grex users who would then grant the access. The
validators might ask a question like "how did you hear about Grex" and
wait for a reply. They would not be asking for ID, just a social
handshake. This is probably enough to discourage most spammers and
hackers. Other variations of social validation might include members
vouching for some new user. The exact rules will need to evolve
based on experience.
Probably there should be some kind of limit on the maximum numbers
of emails that can be sent per day even from validated account, as
suggested in a previous board vote. Staff will work on this.
The broader discussion of restructuring Internet access classes
hovered around variations of the following proposal, which was NOT
voted on:
There would be three classes of users:
Class 1: No Internet access. Can send and receive mail only
to local Grex account.
Class 2: Full E-Mail and HTTP. Users can send and receive
email from or to any address. They can also access the
web from Grex (eg, by using lynx).
Class 3: Full net access. Full access to the Internet,
including telnet, ssh, ftp. What members have today.
All new user accounts would be created in class 1.
Promotion from class 1 to class 2 would be via some sort of
social validation method, as described above.
Promotion from class 2 to class 3 would require some more formal
validation, that actually identifies the users, like mailing in
a photocopy of a drivers license, or sending in $1 via pay pal.
Once in class 3, accounts would not need to be revalidated. The
reap processes would be modified so that those accounts would stay
around for a long time.
Becoming a member would be sufficient, but not necessary for joining
class 3.
Areas of debate included whether http should be in class 2 or class three.
It is at least as abusable as any of the protocols in class 3. But there
is also real value in giving ready access to it easily. Giving such
access is a key part of Grex' traditional charitable mission.
Which raised questions of what Grex's charitable mission should be in
the next three years. Something that needs thinking about, but which
we did not have time to fully debate.
Decoupling membership status from net access would likely cost us a
few members.
Schedule Next Meeting:
The next board meeting will be on Sunday, May 20 at the home of Lynne
Fremont.
Staff Report:
The staff agreed that they had nothing of note to report. I guess that
wasn't worth moving the end of the agenda after all.
New Business:
The membership of board member Jan Wolter had expired. The reprobate
ponied up some cash to restore his active board status.
Closing Gavel Tap: 9:20pm
16 responses total.
I guess I should have kept notes during the joint staff/board meeting.
I didn't. This is from memory. It was not run as a formal meeting, but
as a discussion to establish some ground procedures for how staff should
work.
Traditionally the Grex board has operated by consensus. We would regularly
meet, discuss things that needed to be done, and reach a consensus on how
an whether they should be done. This worked very well for many years, but
in the last few years has largely broken down. Staff has actually met very
infrequently, and it is hard to come to consensus if you only discuss things
on-line or in email. Furthermore, many of the staff people who used to be
very active (myself and Marcus, notably) are now much less active, and do
not always keep up with the current issues on Grex. They've become kind of
intermittant staff. How do you form consensus with people who aren't even
listening to the discussion? We also increasingly have staff in remote
locations, which makes meetings to reach consensus more difficult.
Suggestions arising out of this include:
- Staff should resume meeting regularly, probably bi-monthly at least.
The conference phone should be available, so people can call in.
(Staff has not, however, scheduled it's next staff meeting. I wonder
if we should make a habit of meeting after board meetings?)
- The staff conference is to be considered the main place for discussion
of things to do. If a staff member raised a topic in the staff
conference, and got no negative feedback, they are welcome to feel
free to go ahead. They don't necessarily need to seek input from
people who aren't currently actively reading the staff conference
and keeping up on things, though they may, in some cases, WANT to
do so. We understand that staff members are sometimes busy and have
to drop out of the loop for a while, but things need to be able to
go on without them if they are out of the loop.
- Some things don't actually require a lot of staff consensus.
In an emergency, the staff on hand need to act independently on their
own best judgement. They should obviously make an effort to inform
other staff of what they are doing or what the did.
Some changes to Grex are fairly limited and local. If you are
installing a newer version of 'tcl' that has very limited impact
on the system. The only thing you're doing that a regular user
couldn't do is putting it in a system directory where everyone
can easily access it. Modifying things more central the operating
system that might impact other parts of the system or overall
system security would require more discussion.
- Of course, other changes may require broader discussion in the
coop conference and/or at a board meeting. These are changes that
impact the user interface routinely experienced by many users,
or changes that have policy implications.
I'm just curious as to whether the board should be so involved in making technical decisions about the system. I would think that the board should be either considering requests fron the staff, or putting out to the staff what it would like to see happen. (I know there is some "cross-decking" here, but they are separate.) IE: The board could ask the staff if there is a need/want to upgrade whatever part(s) of the system. Or, "We've decided we want the mobo upgraded to accomodate better remote console. Let us know what you come up with, within two months."
Is the BoD running Cyberspace Communications, Inc., or Grex? I mean, if Cyberspace Communications is doing a bunch of other things other than Grex, then yes I can see Grex as being outside their span of control. But they aren't, so it isn't.
Re the first sentence of the second paragraph of Response 1, above: Should "Grex board" be read "Grex staff"? Re Response 2: Which Board action does NOT comply with your suggestion or question, krokus?
Re IRS Form 990: The form has to be completed, but it shouldn't be that difficult: fill in the identification information and then check the box that indicates an income below the threshold.
We do try to limit technical discussions during board meetings. But often a "hey could we do this?" question comes up, and the geekier people present start scratching their heads about how that would be done and we get some serious disk-drive-stepping-rate class discussions. The president, or any other person who gets annoyed first, generally cuts this off pretty soon and asks that the staff figure it out some other time and come back with a recommendation. Obviously the board should focus on policy topics, but the question of what is technically feasible must inform that, so the pendulum swings back and forth.
Addendum:
After the board meeting, there was a brief staff meeting. One of the
outcomes of this meeting was a recommendation to add Dan Cross to staff.
Seeing that the next board meeting is rather far away, and wishing to
act promptly on this matter, the board entertained an email vote on the
subject. Jan Wolter made a motion, which, in deference to tradition,
should have been worded as follows:
I move that Dan Cross be appointed to Grex root staff with all the
privileges and responsibilities appertaining thereto.
However, Jan brain was on vacation and instead he said:
Jan Wolter moves the Dan Cross be appointed to staff.
In any case, five affirmative votes have been emailed in from Jan,
Colleen, Larry, Bruce and Lynne, so the motion passes.
Dan has been added to the wheel group, which I believe is sufficient
to get him off the ground. We will postpone the annointing with
stinky oils until some representative can make it to New York.
re 4b It was the whole report pertaining to the upgrade(s). It left me with the impression of micro-managing the process. But Jan's answer makes sense, and I can fully understand where that would happen. (I would probably be just as guilty in those settings.) I was just pointing out what stood out at me.
May I take this opportunity to welcome Dan back to staff? Nice work, all. Thanks for doing the admin that keeps this place up.
Re #8: Technical discussion tangents have always been part of board meetings. At one time, there was a tradition of having someone call out "techie digression alert!" when it began to get out of hand.
welcome back to staff cross; can you fix either/both the umich email bouncing adn or the concatonatinfg emails problmke?
Eventually yes, but probably not right now.
(I suspect the umich problem is in the configuration of TCP, NOT SMTP.)
It also seems to be happening with gmail.
Doesn't change my suspicion. I just wish I had time to delve into the TCP configuration. :(
Perhaps the best course of action is to proceed with the OpenBSD 4.1 upgrade.
Response not possible - You must register and login before posting.
|
|
|
- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss