Process for granting access to non-code resources #212
Comments
|
Sounds good to me! |
|
Aside from how to grant, I would suggest that we maintain a list of which people have access to what, so that ad-hoc requests can get to those that can fulfil them in the case that there is no need to grant a new person extra permissions. This list should probably be visible to members of the dask github org. |
|
Is there a way with Twitter, YouTube, etc. for people to send proposed content? Wonder if we can improve this workflow on both sides by making it easier for people pushing content to get things mostly ready to go as well as make it easier for reviewer to approve Should add I definitely don't know the answer to my own question, but wouldn't be surprised if someone who does marketing for a living knows of such tools (and maybe has some suggestions they could float here? ;) |
|
Will there also be a process for removing access later on? Misconduct is mentioned above, but I mean for much more mundane reasons. For example, last year while I was working for Dask I was granted access to the Dask twitter account via TweetDeck. This year I'm working somewhere else, so there's less of a pressing business need for that access today. Or to continue the example from above. Let's say Adi is granted access to the Dask YouTube channel. In my imaginary future, Adi might spend many happy years working for Coiled before getting a great job somewhere unrelated. What happens to account access then? People are mostly pretty responsible, so it's not like. anyone/anything is being harmed. But it seems like a sensible idea to re-review and possibly prune access lists, I dunno, every 12 months or so. Do the code repos have a process for that we could re-use here? |
|
I am good with the proposed plan, but I totally agree with Genevieve and John's points about transparency and process. I think particularly if there are not good options for review processes, then it would be good to keep the access lists short. But in terms of review process it might be as simple as a new repo where the only thing that happens is an issue is raised for every proposed new tweet and there is 24 hour comment period or something. |
|
Thanks for your thoughts, all. I thought it would be useful here to try to summarize (to the best of my ability) the discussion above and make a more concrete proposal incorporating the various discussions: Overall, people seem to be open to the idea of sharing non-code resources, but have some concerns around how access would be granted, controlled, and maintained. There is also some concern about reviewing posted content. I think it's fair to want to have some process around that, but should also be weighed to a certain extent against deadlocking of posting (i.e., too extensive of a review process and nothing will get done). Specific proposalFor the purposes of this proposal, I'll often use Twitter as an example, but I'll try to be fairly general and suggest people make mental substitutions for YouTube, Google Analytics, etc. Access
Posting policy
Thoughts? |
|
I'll propose with the general policy of "whatever we do for code access". I would prefer (mildly) to avoid making new systems/rules if we can avoid it and treat non-code resources similar to code-resources. I think that this will make it easier for everyone to remember. Access lists today are managed in each platform, typically how they are handled in github. For example for Twitter we tend to use Tweetdeck, which maintains a list of people who have access. For Google Analytics Google Analytics itself tracks this. I'm inclined to use these for visibility, rather than also have a separate list somewhere. I doubt our current ability to maintain a separate list and keep it up to date and visible to the group.
For access removal our current policy for owners is that after someone goes dormant for a year we propose to them that they be ok with being removed. They can ask to stick around for another year. After two years of inactivity folks can remove them regardless. This system has never been activated (to my knowledge) which has also been totally fine I think. I think that doing nothing has been swell :) For Twitter itself (or any messaging) we've had existing guidelines at https://marketing.dask.org/en/latest/ . I encourage people here to take a look at that page. I'm totally open to changing our policy for access/visibility/etc.., but I'd prefer to handle this more globally, rather than special-casing assets like these. |
To be clear, I also prefer fewer processes :). But I'm also trying to respond to my reading of concerns that other people brought up in the above discussion, which I would broadly describe as "We don't really know who has access to these resources today, and why". I think one way in which this is a bit different from code access is that some of the proposed owners are a bit less visible on GitHub than those of us who spend all day working here.
This is a fair critique. But I'm also not sure that "whatever we do for code access" means a ton to me given the different nature of these resources. |
Yeah. I acknowledge the concerns as valid. There are lots of other concerns that are possible as well. I think that all concerns need to be balanced against procedural difficulty of satisfying those concerns. I don't think that we should try to create a policy that satisfies all concerns. So, for folks who raised these concerns, are they important to you? Or are they things that would be nice, but that you personally probably wouldn't invest time in helping to maintain? |
|
As an example, I'll bring up the retiring access point. We've had a policy on how to retire code access since we created the project. Fortunately this policy requires zero maintenance (woo! 🎉 ). That's especially good, because we've never once had to used that policy. I would be unexcited about a new policy that required active maintenance to retire access on new resources mostly because no one has ever bothered to use the existing policy on code resources. If this was in frequent use then that would be a good signal that people cared about this topic in practice. We don't have that signal today. There is a cost to policies. We should acknowledge that cost and minimize it where easy. If folks want policies that require effort then that's fine, but we should have some negative pressure there. I think that expectation of actually providing some of the maintenance efforts is a good negative pressure. Otherwise I think that we end up with a set policies that require work but go unmaintained. Our current policies are nice because they are free to maintain. I would like to see that continue for as long as we can manage it. |
|
Normally would assume that when people raise concerns, they view them as important. Additionally the fact that there may be other concerns that could be raised, but weren't, suggests that folks have already downprioritized unvoiced concerns as they didn't deem them worth mentioning separately. So I think we are already looking at the important policies. Anyways my understanding of this issue is we are soliciting ideas about what process we should have. If we are not going to integrate that feedback, then I'm unclear on the goal of this discussion. That said, if the critique is a particular implementation of these policies are hard, perhaps it is worth spending time discussing how to better implement them. Thus far the suggestions seem pretty reasonable with an eye for simplicity and focus on what is relevant. Keep a list of who has access (sounds like Twitter and Google Analytics have clear ways of doing this). Try to streamline the content proposal process to lighten the load on both proposers & reviewers (Is this trivial to do with TweetDeck? Others?). Periodically (annually?) review and prune access (do Twitter, Google Analytics, etc. already prompt us about reviewing access or can they be made to do so?). Combining good policies with good implementations is key. Suspect the answers are already in the tools we are using. At this point I wonder if it would be helpful to have a person doing this marketing work engage here directly. It is possible they see trivial ways of implementing these things that we don't. They also may find different fuzzy spots that should be clarified further that we wouldn't have caught otherwise. |
|
I’m fine with using the platform’s built-in system’s to manage / view who has access. If problems come up then we can address them with stricter, and more time consuming, policies.
Tom
… On Jan 21, 2022, at 7:48 PM, jakirkham ***@***.***> wrote:
Normally would assume that when people raise concerns, they view them as important. Additionally the fact that there may be other concerns that could be raised, but weren't, suggests that folks have already downprioritized unvoiced concerns as they didn't deem them worth mentioning separately. So I think we are already looking at the important policies.
Anyways my understanding of this issue is we are soliciting ideas about what process we should have. If we are not going to integrate that feedback, then I'm unclear on the goal of this discussion. That said, if the critique is a particular implementation of these policies are hard, perhaps it is worth spending time discussing how to better implement them.
Thus far the suggestions seem pretty reasonable with an eye for simplicity and focus on what is relevant. Keep a list of who has access (sounds like Twitter and Google Analytics have clear ways of doing this). Try to streamline the content proposal process to lighten the load on both proposers & reviewers (Is this trivial to do with TweetDeck? Others?). Periodically (annually?) review and prune access (do Twitter, Google Analytics, etc. already prompt us about reviewing access or can they be made to do so?). Combining good policies with good implementations is key. Suspect the answers are already in the tools we are using.
At this point I wonder if it would be helpful to have a person doing this marketing work engage here directly. It is possible they see trivial ways of implementing these things that we don't. They also may find different fuzzy spots that should be clarified further that we wouldn't have caught otherwise.
—
Reply to this email directly, view it on GitHub <#212 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKAOIQX6NAHEUUMDRR27XLUXIEGBANCNFSM5L5HCTPQ>.
You are receiving this because you are subscribed to this thread.
|
I apologize if I've offended. This generally isn't my experience. My experience is that in OSS conversations people like bringing up all sorts of academic concerns. Usually I like asking questions like "is this important enough that you would volunteer personal effort here?" to verify that something is important to people. Usually the answer is no.
I think that gathering feedback is very valuable. I don't think that we should make a policy that satisfies every concern. As with code, trying to implement code that solves every possible feature often leads to ungainly and difficult-to-maintain code.
+1 If these are genuinely things that people care about then awesome. Let's find a lightweight way to address them. My current guess based on historical behavior is that no one is likely to actually care. We spent a long time working on the governance doc and no on other than me has ever triggered anything in there. To be constructive, I'll suggest the following:
This policy gives any member the ability to get access, clean up access, and see visibility, but it requires no additional tracking or maintenance. It delays costs for things like visibility, which I think makes sense if we don't expect a high volume of requests. |
|
Regarding visibility, if folks actually do care about visibility of access I encourage them first to lobby for a requirement that owners flip the "public" visibility bit on github. This seems like a much more serious visibility concern than anything mentioned here, and has similarly never come up. Regarding cleanup if folks actually do care about cleaning up then I encourage them to look through the current list of owners and committers, compile a list, and send out e-mails asking if they don't mind having their access revoked. |
|
Perhaps instead of being concerned about access lists and public visibility we should flip the conversation around to "what steps need to be taken if access is ever abused in the future?". It seems to me this is what we are trying to guard against. If we take Twitter access for example, there is a risk that someone could leave the community with hard feelings (not thinking of anyone in particular, more that these things do happen) and if they still have access to that account they could tweet content that would be damaging to Dask. In the event of that happening someone would need to step in, revoke access, clean up tweets and potentially issue apologies and other damage control. Having a list of who has access could be a useful tool during an incident like that. But equally if compiling a list like that is quick and easy in the moment then it probably isn't worth trying to compile that list now and keep it up to date. I would suggest that keeping a list is a lot of effort for little return in this example as TweetDeck shows who else has access. Equally, I think assuming that everyone with code access should have all access feels a little heavy-handed. It is common in InfoSec to try and keep privileges as constrained as possible. I'm generally in favour of handing out any access to any trusted community member, but would be keen that access should be requested when needed, not offered because that have other privileges. The only caveat would be ensuring the admin bus factor is kept to something sensible on all platforms we use. @mrocklin's suggestions above seem good to me. I would add that we should consider documenting what platforms we use and how to find out who else has access in case of an incident like the one above. Perhaps another useful activity would be to assign key folks as responsible for the platforms we use, sort of like having a designated first aider in an office setting. For example @ian-r-rose would likely make sense as the Forum First Aider, perhaps @jrbourbeau for GitHub, etc. Those folks would be the go-to contact for resolving issues on their platform and if they leave the community they should be actively replaced. |
|
Sidenote there is a great podcast about InfoSec called Darknet Diaries and they did an excellent episode the other day about revoking access when folks leave. |
|
If folks want to own setting up those processes, like tracking who owns what, then I support them in that endeavor. I don't think that it'll get used much, but who knows? I think that a lot of my orneriness on this topic comes mostly from people asking that "we" do things but then no one actually doing those things except for me. Now that I've been hit by a bus I doubt that anything that requires upkeep will actually happen unless I do it personally. However, if folks are actually volunteering here then that's a totally different situation, I definitely don't want to get in the way of that. I'm all for people getting more engaged. |
|
I broadly agree, as far as I can tell nothing is broken and we don't really need to fix anything here.
|
There are a variety of resources like the twitter feed, youtube channel, google analytics, and so on. Today it is not clear how we can hand out access for these resources. This is coming up specifically as Coiled marketing folks try to contribute to Dask marketing efforts. My understanding is that folks generally are happy for them to help, but don't feel comfortable handing out permissions (reasonably so).
I propose that we use a similar policy as we do for handing out commit rights over major code repositories
So for a concrete example Adi from Coiled wants access to the Dask YouTube channel. If I (Coiled), @jacobtomlinson (NVIDIA), and @jsignell (Saturn) all agree then we would be ok granting her access to that channel.
Of course, if something were to be misused or a conflict were to arise then that access would be revoked, much like code access.
Please let me know if there are any serious concerns with this approach.
The text was updated successfully, but these errors were encountered: