[generic] Standing policies

Alex Dehnert adehnert at mit.edu
Sun Apr 9 03:39:09 EDT 2017


I am totally in favor of spreading out Guild standing policy renewals and 
desyncing them from elections meetings.

I also have Opinions about governing documents. Faced with an excuse I 
will expound on those opinions on our neighborhood general discussion / 
flamewar list. <_< >_> Hopefully this is more useful/interesting than 
irritating. (I don't have strong views that the Guild should make any 
changes, so nobody particularly needs to read this. But hopefully it's 
interesting for some people, and maybe some of it -- especially a 
bugtracker -- will strike other people as worth doing.)

Veronica and I rewrote Tech Squares governing documents a few years ago 
(http://www.mit.edu/~tech-squares/govdocs/), and ~copied Guild's 
constitution / standing policy split, with our own "improvements". Some 
things that we've done that I think we've been pretty happy with:

* Our policies all expire in the fall by default, and we intentionally 
scheduled them to have spread out expirations. (We actually originally had 
them all expiring in the spring, when our elections are. We concluded 
after one cycle that that sucked, and moved them to the fall. We also have 
a lot longer policies, I think, partially because the bylaws that predated 
them are also kinda long.)

* We track a scheduled review date separately from the adoption date. 
It's certainly not required, but it's somewhat nice to have, and gives an 
easy way to do things like "we should review this pile next time at 
different times". I've also been figuring that it's less interesting to 
know the last reapproval time than when it was adopted or seriously 
amended, so that's what we track.

* We have a bugtracker that we use with our governing documents (we're 
using GitHub issues, because that's where the govdocs repo is hosted -- 
https://github.com/tech-squares/govdocs/issues). I think it's pretty 
common to discover issues with govdocs when, eg, noticing something stupid 
at an elections meeting. It's nice to have somewhere standard to queue up 
issues until the next standing policy review cycle. Our standard has been 
to, each review cycle, (a) re-read the policies up for renewal and (b) 
look over the issue tracker. In general I think a standing policy system 
with renewals, like Guild has, has a lot of potential to keep the govdocs 
from getting out of a sync with actual practice, and I think an issue 
tracker and reviewing all the issues filed annually can make that work 
even better. (Guild's shorter policies probably make this a little less 
useful than for Squares.) I also think a bugtracker is particularly useful 
with something like a constitution that's not regularly amended (when it 
is, it's sorta nice to deal with the minor stuff too), but it's useful for 
standing policies too.

* We allow the group as a whole to make policy amendments, with advance 
notice, and the Executive Committee to make changes too, with some time 
for group members to object (if enough objections happen, then the group 
as a whole must approve it). Tech Squares members tend to really hate club 
meetings (more so than Guild members do, I think) so keeping the normal 
review process out of club meetings (which are during dances) is nice, but 
I don't think people would have been happy letting the EC make changes 
without oversight.

* As a general principle, the easier it is to amend standing policies, the 
more reasonable it is to put things in that are currently believed to be 
good ideas, but that people figure could very easily change. For example, 
Tech Squares has a long-ish duties section in the standing policies -- I 
don't think we'd do that in something that wasn't regularly reviewed. With 
a regular review process to make sure things aren't more than three years 
old (usually), the standing policies can also serve as a ~useful form of 
institutional memory.

Anyway, lots of text. Not necessarily super-relevant for Guild. Hopefully 
some people found it interesting anyway (hey, maybe others are writing 
group govdocs). I'm also happy to talk more about govdocs if people are 
interested...

~~Alex

On Sun, 9 Apr 2017, Laura McKnight wrote:

> The spring meeting of the Assassins' Guild will be at 1pm on Saturday, April 22nd. We will be electing new members of the high council, so if you are interested in running or voting for the positions,
> please attend! Current students: The Guild can't continue to exist unless we have current students to fill some of the positions. There will, as always, also be free food!
> 
> If you would like to nominate someone for master (either as a GM team or by filling out a petition) please email high-council at mit.edu. Petitions are due before the meeting starts. For more on the
> master nomination process see our constitution at http://web.mit.edu/~assassin/Constitution/constitution.pdf.
> 
> If you have a vote and will not be at the meeting, please send the High Council mail either renouncing your vote or giving your proxy to someone who will be present.
> 
> Agenda
> 1. Food
> 2. Officer Reports
> 3. Elections
> 4. Master nominations
>   (if anyone is nominated)
> 5. Discussion of the standing policy renewal schedule
> 
> 
> Discussion of the standing policy renewal schedule
> It looks like by some means or another, all of our standing policies expire in three continuous terms, in which we would need to renew 3 standing policies a meeting. As of now, 3 standing policies
> will be up for renewal in Spring 2018 (an elections meeting), 3 standing policies up for renewal in Fall 2018, and 3 standing policies up for renewal in Spring 2019 (an elections meeting). I'd like to
> suggest pre-emptively renewing these in future meetings, and possibly changing it to so that standing policies are renewed in the off cycle from elections meetings. This would not require any sort of
> constitution change or official policy change. If you have strong feelings on the subject, please reach out to me before the meeting.
> 
> 
> -Laura McKnight
> Scribe
> 
>


More information about the generic mailing list