Admin permissions need to reflect defined responsibilities

[Mitzi-Laszlo]

At the moment there is no clear description of why people have what Solid admin privileges. The reason why I want to bring this up is that I want it to be clear who is responsible for what.

Would you agree that it makes sense to reflect admin privileges to the Solid team role and responsibility descriptions? If not, what would be an alternative approach?

Before doing this it's important that the people allocated are accurately reflecting who is working on what. If you are working actively on Solid please have a look at #44 to make sure that your activities match your responsibilities and vice versa.

Other than GitHub are there any other Solid tools? For example, there's a Linkedin page that I am admin of that I would like to be stated in my role or another to make it transparent. There is also a Facebook Solid page that I believe is held by media prophet. Also there is the Twitter MIT page who I'm not sure who is holding that. Maybe the solid gitter? Anything else?

[HuVote]

Imho I think the Pod when first issued should be assigned to a 'Core' Network. Country for instance to start with and can then go on and join additional Pod Networks. Few reasons for this, first is in order to maintain as much control over Solids vision u will need a way to measure. This will help with this as it all plays out. Secondly we require a hierarchy of admin privileges in place. The 'Oracles/agents' of each Network is where the buck stops so to speak. They are the ones Entrusted with the retrieval of a user's data which would be (recommended) if a user forgets a pass phrase/dies etc. That option will be an owners choice. There will be Pods that don't use that back up due to the unrestricted nature of a pod. I digress... Once this is in place maybe a simple way to do it would be maybe to rank privilege access levels numerically in decending order. When something requests access to a users Pod segment which houses the information. That Pod/user could then grant whatever level clearance they choose. I.e Level 6 (View only)

[HuVote]

Once the system hierarchy is in place then you can structure the (Who's doing what) aspect. I totally agree of its importance. Eliminating the 're creating the wheel' element increases the pace of the mammouth task ahead!!!

[TallTed]

@MattDorrian - Note that you can edit your prior comments, so you can fix the typo, changing "untrusted" to "entrusted" (the much more common and, I think, better understood spelling of "intrusted") ... and then delete the commentary-correction.

[HuVote]

Thanks Ted I stand corrected and totally agree. Did try actually but panicked as untrusted is the polar opposite of what we are looking for!!!

[HuVote]

Mitzi. The time has come to gather all important research, chat platforms, ideas, etc etc "In House" I've witnessed likes on pages vanish, along with the actual pages, and websites vanish off the face of the earth never to be retrieved. Practice what you preach, start the process of protection and then direct people where they need to go. People that are looking will find this and anyone opposed literally can only just sit and watch.

[megoth]

@MattDorrian if I understand you correctly, you suggest this as a way of administrating the hierarchy of PODs within an organization, or maybe more specifically a POD provider setup? Although it is an interesting approach, and might be something we want to consider when setting up more formally structured organizations using PODs, I don't think it's applicable for now for this issue.

The way I understand @Mitzi-Laszlo original post it's rather a question of how we make sure that what is presented as official resources for Solid is in control by the community and how we can be transparent about it. We're setting up formal structures in this repo, and Mitzi is wondering if we should use these structures also when it comes to the control of resources.

I think yes, it makes sense that these structures also covers why people have admin rights. But I think we should organize these transitions carefully, and be flexible by adding minor roles. E.g. a lot of people have admin rights to solid/chat, and it would create chaos and split the community if people lose those privileges.

At some point it might make sense to transition to a more coherent structure as proposed in this repo. So let's start by creating an overview, and understand the extent of the current de facto admin privileges before we transition it into something else.

Does that sound ok?

[HuVote]

Megoth I fully understand the thought process.
"The way I understand @Mitzi-Laszlo original post it's rather a question of how we make sure that what is presented as official resources for Solid is in control by the community and how we can be transparent"
My fear is a few steps have been missed.... People asked 'how' you have twice. I think all I offer is an idea of how If you started at the top. the heart/core of the system and then work backwards to giving individuals goals, tasks assingments etc then the above method pans out (ish) as the positions We think Mitzi is looking for will be designed by the structure of the system. by all means start giving people titles, 'Chief of Solid testing' etc to expedite the process but at some point you will have to define those possitions. I hope that makes sense. I think my point is that what you desire to transition into should already exist.
More than happy to help

[Mitzi-Laszlo]

@MattDorrian Indeed, although your point about Pods is very interesting in this thread I was talking about tools such as GitHub, Gitter, Discourse, Reddit, LinkedIn, and Facebook.

@megoth good idea, I'll clarify the current situation and make a suggestion about how to make sure the responsibilities are reflected in the admin privileges.

Although 14 days have passed I'll leave it open for an additional 7 days to give people a chance to react to the specifics.

GitHub Organisation Members - include only Solid team?

GitHub Outside Collaborators - include nobody?

GitHub Teams - include only 1) 'MIT Academic Project': academics who formally worked on the Solid MIT project 2) a team per project including the project manager and anyone else who is involved 3) 'IMEC' academics who formally work with Solid from the University of Ghent 4) 'Solid Team' include only Solid team 5) W3C Group include all Solid W3C Community Group Members

GitHub Projects - include the corresponding team led by the stated Project Manager per project

Gitter (all gitter channels related to the Solid GitHub account) - include only Solid team?

GitHub Repos - include only the repository manager and project teams that state they need access to the repo in the project board

LinkedIn - include only Solid team?

Facebook page - include only Solid team?

Reddit - include only Solid team?

Discourse - include only Solid team?

[Mitzi-Laszlo]

Solid W3C Community Group members may want to make a project with a defined goal (?) and get access to the three repositories involving the specs

[melvincarvalho]

This proposal isnt quite right. Both in terms of content and the underlying structure (namely this repo). I think it would benefit from a wider and broader consultation and incubation period. I'd say, push out the decision making into Q2 or even Q3, unless something urgent arises.

Two members of the community (movement?) I'd recommend for this, in addition to timbl, and if you are able to get their time, would be Sarven and Michiel.

It's also important to avoid corporate open source anti patterns.

[megoth]

This proposal isnt quite right. Both in terms of content and the underlying structure (namely this repo).

Could you be a bit more specific about what you think is not right?

I think it would benefit from a wider and broader consultation and incubation period. I'd say, push out the decision making into Q2 or even Q3, unless something urgent arises.

I agree that this isn't an urgent matter, but I also agree to @Mitzi-Laszlo original point on transparency. ("At the moment there is no clear description of why people have what Solid admin privileges. The reason why I want to bring this up is that I want it to be clear who is responsible for what.")

Two members of the community (movement?) I'd recommend for this, in addition to timbl, and if you are able to get their time, would be Sarven and Michiel.

Is this your proposal to how to advance this issue, to set up a working group to flesh out a proposal? I think it's a bit unnecessary bureaucratic, tbh, but if it works...

It's also important to avoid corporate open source anti patterns.

Good points, and a nice read overall, thanks for the share 😸

[melvincarvalho]

Could you be a bit more specific about what you think is not right?

Cant put my finger on something specific and say "Fix X and we're done". A good response would probably be quite lengthy. And I'm a bit snowed under at this minute. :)

The bar is set quite high by open source communities, so I think it takes time to get right.

I've suggested a couple of names that I think have the experience to add value, not a working group, not a proposal, just pointers really to people with good knowledge. There are many others, but those two know solid too.

[Mitzi-Laszlo]

@melvincarvalho not to worry, take your time, let's leave it open another week to give you a chance to think about a suggestion for the specifics of how to move forward.

[melvincarvalho]

@Mitzi-Laszlo thanks!

OK, so basically the way that open source projects is informally based around a web of trust. What does that mean? Well many people contribute over time and folks sort of create a trust network.

It's all good, so long as there are no things that go wrong.

Unfortunately, incredible errors occurred. And we need to sort it out via a post mortem.

Rite, so. It was either Justin or Ruben who came in to our project and deleted repositories, without archiving them. This is a horror story, and absolutely unacceptable. We have yet to understand this.

I am strongly for revoking both the privileges or both individuals (Justin and Ruben), until it is established what happened, why, and that we ensure that it cannot happen again.

Other than that I think things are OK, basically prune inactive accounts, on a long time line is good ... nothing urgent for the moment imho

[melvincarvalho]

@Mitzi-Laszlo you (and others) may enjoy this old but seminal video from Linus Torvalds on the motivation for creating git (as in github).

It is also very amusing. It's quite long, but aside from describing git, he talks for quite a while about how trust works in open source projects. The basic idea being that formal structures (at least according to Linus) are not optimal in open source projects. What tends to develop is people determining their own levels of involvement and a web of trust between devs on different aspects of a project.

If you get time to view it, you might gain a great deal from those insights.

https://www.youtube.com/watch?v=4XpnKHJAok8

[HuVote]

The same questions will be asked over and over again. Archive the relevant ones along with the answers. Human error will occur. If persistent offending is repeated there is more than likely an ulterior motive. Strong feelings are often correct. Worrying is akin to knocking your head against a wall. It only feels better when you stop. All the Best <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

…

On Fri, 22 Mar 2019 at 15:50, Melvin Carvalho ***@***.***> wrote: @Mitzi-Laszlo <https://github.com/Mitzi-Laszlo> you (and others) may enjoy this old but seminal video from Linus Torvalds on the motivation for creating git (as in github). It is also very amusing. It's quite long, but aside from describing git, he talks for quite a while about how trust works in open source projects. The basic idea being that formal structures (at least according to Linux) are not optimal in open source projects. What tends to develop is people determining their own levels of involvement and a web of trust between devs on different aspects of a project. If you get time to view it, you might gain a great deal from those insights. https://www.youtube.com/watch?v=4XpnKHJAok8 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#48 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AtaM2y3JYtwtetclkfgxXAP0NJVnncF0ks5vZPvIgaJpZM4a0jlY> .

[Mitzi-Laszlo]

Is there a place where I can find written instructions to archive rather than delete when working on Solid? To add a note about archiving rather than deleting add a suggestion to the role descriptions on #44 for the Solid Leader to approve.

@melvincarvalho If the archiving rather than deleting concept is incorporated to the roles do you agree to the general principle that admin permissions need to reflect defined responsibilities?

[Mitzi-Laszlo]

Please add your thoughts to the table below, including if you have ideas on other routes forward.

Route Forward	Pros to Consider	Cons to Consider
* Change people to Solid Team as 'owners' and project teams as 'members' * Keep project teams and Solid Team and remove all other teams * ensure that only Solid team are admins of Solid gitter	*everyone who has a role has access to what they need * those who do not have roles cannot action items that others are responsible for * clear descriptions around how people can apply for roles in decision making process	(insert suggestion)
Do nothing	* easy, no effort	*means people have the ability to action changes for which they are not clearly stated as being responsible for

[Mitzi-Laszlo]

associated Pull request on solid/process#78