Proposal: Solid Team should have access to solidproject.org email accounts #47
Comments
|
agree all team members can get and should get acces. Disagree we should remove references to the email as it is actively used and provides value. Not everyone who reaches out via those means uses github, it's often people who want to learn more about Solid and simply seeking direction to content or a conversation with someone to learn more. We often point them to the forums or basic content. |
Only until the whole team has access to the email accounts. Once this is resolved, we can restore the references on the website. If this gets resolved before the website release, we won't even have to remove. |
|
Why would "admins" need to have any particular privilege above and beyond anyone else in the team to send out emails from certain email accounts (info@) except those that are related to "admin" tasks. This is especially concerning when incoming email to info@ (for instance) is not tied to "service" in which the "admins" need to be engaged in. Passwords to email accounts should change. |
My understanding is that once the part you agree with is done, the part you don't agree with will no longer apply. |
|
The info@solidproject.org email address is already listed in the footer of the existing website, and has been since 2019. It is also listed on the Solid Events page and the Solid Team page. So I see no need to remove it from the website due to this issue, given that it is actively being monitored. |
|
@KyraAssaad are you opposed to the whole team, or those who are interested in / need it for their tasks, having access to the email accounts? |
|
I agree with @michielbdejong's points:
My opinion is that only the Solid Team Admins should have access to the email accounts. Or create a new role/group of people who volunteer to manage the email accounts. But I don't think all the members of the Solid Team should have access to the email accounts. If people on the Solid Team need to have access to the email accounts in order to do one of the tasks that they are volunteering for, then that's fine, I'm not opposed to that. |
|
I would not be oppossed to limiting access to the email accounts to specific Team members who had need of it in their roles. I do not believe that an occasional appearance at a meeting or a note in the chatroom constitutes "hovering". If an activity is carried out completely apart from the Team with no expected communication between the activity and the Team, I do not see any reason it should be billed as something the Team sponsors. As a Team member responsible for app developers, I'd like to know generally whether app developers write to the email box and if so what kind of questions they ask. Sure I can go read all the emails, but then why delegate the task? Why is it too much to ask that the person/team responsible for Team emails give occassional informal reports of how many and general what kinds of emails we get? Or to ask us in chat how something in particular could be answered. This is all how I work in my role as forum manager - I bring sticky questions to the team, I refer questions to other team members as appropriate, I let the team know of general trends on the forum. I do not see these as heavy-handed impositions from the team, but as part of my responsibilities. These make me a better moderator because I have a much wider knowledge base to draw on. And they alert the team to opportunities to engage with the community. If I (and Arne and others) did not do those things, there would be no interface between the Team and the Forum and there would be no excuse to claim that the Team somehow manages the Forum. The same should apply to all Team activities. So I support a collaborative model in which task leads communicate with the Team. This does not mean I support the ability of a minority of Team members to block a task - if there are objections about the way a task is done, the team should strive for concensus, but failing that, uness a vote is called for, the task lead should take the team's opinion into account and proceed as they themselves best determine. Nor does this mean that I am in favor of excessive documentation. Reporting back can be a single sentence in the Team chat room. The goal is communication and collaboration, not rules and bureaucracy. |
|
Emails to info@ , for instance, are typically meant for public inquiries and collaboration - which is also implied on the website. This is by definition not an "admin"-only task. If anything, Creators, Editors, Practitioners, and many other groupings are better suited to respond to such inquiries than Admins. Moreover, Admins might unintentionally provide inaccurate responses or hinder community involvement. Ditto press@ . I see no reason why Admins would ever need to engage there. Only the admins historically having access to the email accounts and that it should continue that way is not a legitimate justification either, especially when we are talking about scope and moving things forward to be more effective as a "team" part of a "community". info@ is about a general inquiry as it gets and may need the attention of multiple individuals and roles. There is no reason for Admins to process any of that before anyone. In fact, it should be the other way around. Admins can be called up when there is a typical technical admin concerning matter, e.g., "I'm using Internet Explorer 5, I can't access your forum; your website is down because you didn't renew the domain, a pretty active admin may want to look into it; I'm seeing certificate errors on your website, is Tim hacking me? I'd like to offer help to migrate the solidcommunity server, heard you had some cash and scripts?" Perhaps also consider the possibility where all Team members having (read, write) access to the email accounts helps to be better aware of things, suggest corrections (even in private) to what someone else has said, a trackable and searchable record of things - which can come in handy in the future. The individuals in the Team can decide for themselves how much they need to engage. If an admin is deemed to make a good call on if/when someone needs to be contacted, so can everyone else in the Team. If admins don't want anyone hovering over their shoulder, we can create admin@ just for them. Email is among one of the communication options of the project. Reminder that no one is preventing anyone or Team roles from reading or writing to GitHub repositories, chats, the forum, or even the CG mailing list etc. The collaborative approach is working everywhere. Let's get to the bottom line: Does anyone have an objection to the proposal here? |
|
So to be clear, no one can send emails from info@solidproject.org, it merely forwards emails to a list of individuals. We get a range of correspondence in there from "Please delete my Pod on solidCommunity" to "Who do I talk to about evaluating Solid for my initiative" and "I would like to file a formal complaint about something" as well as "Your bill for X service is due". Most responses are either admin tasks which get performed by admins (pay the bills, update the accounts, etc. or they are inquires that end in referrals. Usually we refer folks to the forums or a page with additional info on SolidProject.org. Interestingly enough, there is already an admins@solidproject.org mailing list, and info@solidproject.org actually just forwards to admins@solidproject.org. Sometimes personal or private information comes in as a part of the requests, hence why the mailing list was kept small and strictly to admins. But since the reality is there are 2 mailing lists and we're effectively using them as one, we can certainly split them up and have info@ go to a larger group. This does carry the risk of people accidentally sending things that are supposed to go to admins@ to info@. The consequence of which is peoples personal/private information going to a wider group then intended. We can try and mitigate this risk by making that as clear as possible on the website. Additionally, you'll likely be exposed to some account and billing details you shouldn't be. At least until we can update all the accounts to go to admin only. I'm not particularly comfortable imposing this increased risk on Solid team members without their explicit consent. But if people feel strongly and want to opt-in, and the team make the decision, we can add them. But everyone who opts in should understand and accept the risk of possibly receiving PII in their inboxes occasionally as a result of being in this mailing list. Also, they should accept the reality that they will be cc'd on messages and requests that they simply can't do anything about (and arguably should not be receiving) as they are not an admin. For the record, I don't like this. It goes against the security and operations principles of least privilege, as Kyra pointed out. If people don't need additional information and access to do their jobs, they should not have it. Simply wanting access is not usually a justifiable reason for it to be granted. This is how we set up all infrastructure for the solid team and solid project. But I wont die on this hill as people seem to feel very strongly about it and the volume on this is limited to a handful of requests a month (if even) and some billing and account info we can go update. If we all agree on this as the path forward, then those who want to opt in can drop their email addresses in the team gitter channel (unless they want to post their emails publicly here). I'll await a decision from the team and make the changes if they are agreed on. |
|
What are the assumptions? What measures were considered - documented - to be taken? So, I would like us to make further clarifications about this request, and identify areas to make improvements. This may involve refining transparency within the Team, enhancing communication with the community, and updating various aspects of the Solid Project assets, among other considerations. It's important to emphasise that this isn't merely about subjective feelings; rather, it's a proactive effort to address and improve specific aspects, avoiding any perception that certain individuals are simply doing favours for others. The Team as a whole works together and serves the community.
Any information pertaining to "Terms" of using the website or Solid Project assets should be captured in https://solidproject.org/terms . I am the original author of that document and still to date it only details URI Persistence Policy. I've created the issue Publish a Terms of Service in 2020 and have asked for feedback numerous times. The Team can work together to extend the Terms on the website, which would include potential PII matters. Or if so desires, have a separate Privacy page. Opting to receive emails comes with acknowledging "the risk of possibly receiving PII" as well as how to appropriately handle the information. Team/Admin can document and share with the rest of the Team. Better late than never. Allowing the Team to access the Webmail would eliminate the scenarios in which copies of the email are forwarded to different emails / endpoints. Unless additional steps are taken, typically the "copies" of the email wouldn't leave the Team user's Web browser. What Webmail options were considered? Anything in particular preventing the Team from using Webmail for all or some email accounts? Furthermore, all references to the emails from Solid Project assets, e.g., solidproject.org, Matrix chats, Solid Forum, etc., should be reviewed and clarified to ensure the appropriate email accounts are used. Make a clear distinction when someone needs to, e.g., use
are not "admin" tasks. Neither is something like "Please reach out to info@solidproject.org if you want your organization to be included in this list." That statement alone is a simple example acknowledging the general inquiry and falls on the Creator's role, individuals contributing to the maintenance of the website content, and also of interest to the director and the teams/committees such as DEI or CoC. This pertains to whom the project is willing to acknowledge or cooperate with. Lastly, administrators are neither required nor asked to process emails sent to Generally, the Team members who need access to
Importantly, the As for:
We can look into the extent in which PoLP needs to be applied (or how it may be at odds with other principles.) We can work on Solid Project's Principles and Values ( solid/solidproject.org#835 ) and let's see our aspirations and what we can uphold in the Solid Project. |
|
I fully agree with Sarven's points on which groups and tasks need access to email accounts. In addition, I've looked through https://github.com/search?q=org%3Asolid+%40solidproject.org&type=code and what's already been confirmed in discussions and other references:
Based on this discussion, I have listed the groups that I believe should have access to each account under the "Access" column. This list should be added to Team assets. I can PR it once this information is confirmed. It'd be great to have the Admin Team review this list and make sure the list is accurate and complete. @oolivo or @bourgeoa, would one of you please lead this task? This will help us to update the references to the emails as well as making sure access is granted appropriately. Some of those accounts could be removed and we should keep |
Two action items assigned to Jackson in minutes:
@oolivo has responded on the Team chat that the people with access are administrators: https://github.com/solid/process/blob/main/administrators.md
4/6 members of administrators are either former or inactive team members (see #44). In addition, other members of the Team need access to these accounts for their tasks (see scope: #39)
PROPOSAL: all members of the Solid Team (see updated list: https://github.com/solid/team/pull/39/files#diff-7519aafe48e2ca696efec05f9bba9c9037718d4b4f9f9f032a666af5f9a3bc84) should have access to read emails directed to these email accounts.
Until this is resolved and all members of this team have access to those accounts, we should not include any references to info@solidproject.org on the website. I will write it out of the pages where it is used and give alternative means of communication (mostly GitHub since it's the only one we all can see).
The text was updated successfully, but these errors were encountered: