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

[Mark Tearle]

> 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.
> 

Have a look here, click on the link under Admins
http://www.csn.ul.ie/#recruit

The concept of claiming/assigning folk to a service might work (with perhaps a teacher/pupil kind of thing). It did strike me as an idea to explore.

Mark
PS. I'll be back briefly in late June if folk wish to chat about UCC things ...
--
Mark Tearle <mtearle at ucc.asn.au>


On Mon, 13 May 2019, at 11:37 PM, Grace Rosario wrote:
> 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:
>> 
> _______________________________________________
> List Archives: http://lists.ucc.asn.au/pipermail/committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ucc.gu.uwa.edu.au/pipermail/committee/attachments/20190516/36461e32/attachment-0001.htm