[committee] Fwd: Minutes from the meeting that is entertaining

[Grace Rosario]

A friend of mine was listening in on the Groups Review process yesterday
and had some insights into why many of the potential 'solutions' won't
work, and an idea about the actual 'problem' driving this review.

" I think if the issue is trust then this is the wrong conversation. A
better conversation is who isn't trusted, why, should they be removed and
what needs to be changed to do that? "
The above is not what I, personally, think. But I believe that there are
some people in the conversation who unfortunately think that.

I think it might be good to separate these two issues completely, trust and
group review.

If people are not trusted: why, should they be removed, how can this happen
in a fair way?
-- What disrupts trust?

For the group review (which the OGM has compelled us to do), I am still
keen on a survey of interest every year asking individuals if they would
still like to have access to the permissions that they currently possess.
-- If people are like me, then they would lapse their permissions as they
become no longer necessary to them.

Those are my thoughts.

Grace Rosario
[MLG]

---------- Forwarded message ---------
From: Ryan Oakley <21793455 at student.uwa.edu.au>
Date: Mon, 13 May 2019 at 20:37
Subject: Re: Minutes from the meeting that is entertaining
To: Grace Rosario <20483992 at student.uwa.edu.au>


Hi Grace,

So I couldn't help but think about the Wheel problem.

A two tier wheel system is the clear solution. If a change of Wheel needs
to be made to fix this issue.

However I would take a different approach to it.

Let's consider that the benefit of being on wheel is non-monetary. Which
makes things easier as it's more subjective and there no ingrained "more is
better" ideas. As you can't have "more wheel". It's an exchange of value
(benefits, good will and power for responsibility).

With that in mind, you could figure out what aspects of wheel is "painful"
(things people don't want to do or takes a lot of time) and pair that with
what people want less active wheel members not to have (Sudo).

I.e. create a wheel-lite with less power and responsibilities. For this to
work you should,

1. Allow people to volunteerarily step down to wheel-lite through action
(asking for it) or in action (not meeting requirements).
2. It should be easy to move from wheel-lite back to wheel.

This could potentially benefit wheel members, as when they go though a busy
period in their life they can step down to wheel-lite. In addition wheel
members who want to continue to provide their services in steering the club
can do so with less "pain".

Obviously, don't call it wheel-lite.

The downsides are:

1. If you're honest about this new system some wheel may feel offended by
the notion you can't trust them.
2. You could get a growing mass of wheel-lite members who don't do any
technical work. This could occur by too many wheel members becoming lite,
thus more new members are added to pick up the slack who then become lite
members repeat. If this occurs you could adjust the wheel-lite requirements.

The other ideas,

Super wheel loses the value of a dual governance system that UCC having
both a representative democracy and a democracy of professionals
(autocracy). if super wheel is elected It also comes with all the potential
problems of committees (win-lose of democracy, more politics, a few
inflicting their will on all, less voices and non committee members not
doing work (or having the freedom to do work).

Project based giving of Sudo. The idea is that Sudo will only be given when
needed. This makes it harder for getting work done, especially for more
casual members. And creates a governance nightmare around giving and
removing keys.

Git: not quite sure what the maths guy thought this is. But I think it's
idea of creating scripts so machines can be reset at will with a button
click. Good idea but doesn't really solve the issue of trust other then
creating version tracking. Plus, part of the job of wheel is tech support
which usually can't be done via run once scripts. client machines can't be
perfectly set up via a script as users touch them and want to use them in
unpredictable ways. That said a pre-scripted or created base box is a good
idea but I'm pretty sure UCC already does this.

Also a dedicated issue board would be a big improvement, as currently I
believe to report technical issues door members attempt to contact a wheel
member via messages. This could easily be done via GitHub issues. A shorten
link to the repo should be created and posted somewhere in the clubroom or
ideally create a UCC desktop wallpaper and deploy it to all the machines.

With that said, I think changing governance for this reason is pointless.
If the concern is the a wheel member becoming a potential attacker then
none of this will stop them becuase social engineering is a thing. A little
social engineering will get any wheel member Sudo on any machine or all of
them.


You can't get around giving system administrator extreme power. So don't
have system administrator you don't trust. Easier said then done though.

There is the obvious solution that all command line inputs under Sudo must
checked by another wheel member via code review before being executed. But
wheel members will hate this becuase it's terrible not to mention it would
take ages to do anything.

You could also break wheel into roles, i.e. each wheel has a single
responsibility and can't change things on other machines. But this only
reduces vectors of attacks and impact. It will make it harder for people to
do their volunteer work and put more delays to fixing stuff. Not to mention
where a wheel member (s) in charge of something are unavailable.

I think if the issue is trust then this is the wrong conversation. A better
conversation is who isn't trusted, why, should they be removed and  what
needs to be changed to do that?

 Or reduce vectors of attack. Do a risk assessment of a wheel member going
rogue, the impact and cost of fixing it. Then take measures to reduce
impact and cost of fixing.

Make a disaster recovery plan and find a way to protect sensitive data. And
obviously make sure logs are protected. This assuming none of this isn't
already in place.

I think this primarily a  person and technology problem not a governance
problem.

This isn't a formal analysis as I don't know enough about UCC's governance
to do that and I am lacking some important information.

I hope this helpful.

Thanks,

Ryan Oakley

On Mon., 13 May 2019, 6:42 pm Grace Rosario, <20483992 at student.uwa.edu.au>
wrote:

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ucc.gu.uwa.edu.au/pipermail/committee/attachments/20190514/8a78ed79/attachment.htm>