Update README.md to suggest how users should

[chrisb13]

As discussed with @ccarouge @aidanheerdegen this afternoon, this text is currently misleading as a mixed approach is being used where eventually the plan is to move to a per repository access basis. Perhaps text like I've suggested could be used eventually?

Here's an example where it's been confusing for own staff. Shame GH doesn't have a join button!

Alternatively, can this text please be updated to reflect the current mixed approach? Have admins of all the current organisation's repos been informed of the change / update of the READMEs as appropriate?

FWIW, here is what I've proposed for esm1.6, along with an issue template:

You need write access to this repository. To get write access, you need to create an issue and request access.

[chrisb13]

ping @aidanheerdegen @ccarouge @micaeljtoliveira

[micaeljtoliveira]

@chrisb13 I agree that the text needs updating. I've made a small suggestion to make it clearer.

[chrisb13]

Thanks for the update @micaeljtoliveira

What is the status of this?

Have admins of all the current organisation's repos been informed of the change / update of the READMEs as appropriate?

I hadn't on the esm1.6 one but I'm not an admin. Were you aware @blimlim?

[micaeljtoliveira]

What is the status of this?

I don't think this has been done yet.

[blimlim]

I hadn't on the esm1.6 one but I'm not an admin. Were you aware @blimlim?

Not previously, but am now!

[chrisb13]

Thanks both. I don't think we can merge this until that has been done. The new instructions are otherwise misleading.

@micaeljtoliveira can you please merge once that is completed. Just a thought, could save people some work to have examples of how that's been done, so feel free to share this example.

[micaeljtoliveira]

@chrisb13 FIY, we are now moving forward with the changes to this org management. See #2.

[chrisb13]

So is the plan to merge this?

[micaeljtoliveira]

So is the plan to merge this?

We discussed what's the best way to communicate the proposed changes, as there's no obvious communication channel to all the organisation members. One suggestion is to use a PR in this repo to ping all users and/or repo admins. If we go with that idea, it's probably better to open a new PR and implement all changes to the Readme there.

[chrisb13]

So is the plan to merge this?

We discussed what's the best way to communicate the proposed changes, as there's no obvious communication channel to all the organisation members. One suggestion is to use a PR in this repo to ping all users and/or repo admins. If we go with that idea, it's probably better to open a new PR and implement all changes to the Readme there.

Oh I see, sounds prudent but can't you just ping everyone here or am I missing something?

Also, how did you find this PR? I can't actually see a way to browse PRs that are at an organisational not repo level?

[micaeljtoliveira]

Oh I see, sounds prudent but can't you just ping everyone here or am I missing something?

Yes, we could, but this PR has already quite a few comments that could make things confusing for the people being pinged.

Also, how did you find this PR? I can't actually see a way to browse PRs that are at an organisational not repo level?

I don't think there is such a thing as a organisational level PR. This PR is part of a repo. Although it's treated in a special way for some things, it's still a normal repo for most purposes.

[micaeljtoliveira]

@chrisb13 Just to let you know that I've included the edits from this PR here this new PR.

[chrisb13]

Thanks @micaeljtoliveira I don't quite follow, I think you're saying there's a new pr with content from this pr but the link you gave is an issue?

[micaeljtoliveira]

@chrisb13 Sorry, I meant #3

[chrisb13]

Thanks @micaeljtoliveira, I've had a look at the new PR.

I think it's great to have clarity around the roles and responsibilities.

I do think though that we could make an effort to be consistent across the org' on this point:
The procedure to request access should be described in the README of each repository.

Can't we have the same new issue template across al the repo's? It means users have the same experience regardless of the community repo in question. I don't think there's a reason to have different approaches across different repos? Similarly, should we also have a policy on the kind of licence and fix it for all new repo's?

[chrisb13]

Closing this PR as it's being picked up over here: #3

[micaeljtoliveira]

I do think though that we could make an effort to be consistent across the org' on this point:
The procedure to request access should be described in the README of each repository.

Can't we have the same new issue template across al the repo's? It means users have the same experience regardless of the community repo in question. I don't think there's a reason to have different approaches across different repos? Similarly, should we also have a policy on the kind of licence and fix it for all new repo's?

I would prefer to leave these decisions to the admins. Each group has it's own preferences and user base and I think they are the ones that know best how they want to handle these things. This is particularly true for the choice of license, which can have far-reaching consequences and requires careful consideration.

[chrisb13]

This is particularly true for the choice of license, which can have far-reaching consequences and requires careful consideration.

Question (that I don't know the answer to!) of all our repos (across both organisations) how many of them don't currently have a licence? If the answer is high (my guess is that it is), is that a concern? I'm not sure leaving it to the individuals (who don't feel qualified) fixes the problem.

Similarly for the READMEs and joining, are we okay with many repos not detailing what the policy is?

[micaeljtoliveira]

Question (that I don't know the answer to!) of all our repos (across both organisations) how many of them don't currently have a licence? If the answer is high (my guess is that it is), is that a concern? I'm not sure leaving it to the individuals (who don't feel qualified) fixes the problem.

In the ACCESS-NRI org, there are less than 30 public repos that are not forks that don't have a license (out of 113). In the ACCESS-Community-Hub org, there are less than 10 repos without a license (out of 29). Not having a license is not necessarily an issue, as some repos do not store software and their content is not meant to be distributed.

Similarly for the READMEs and joining, are we okay with many repos not detailing what the policy is?

No, we are not okay with admins not advertising how people can request access, but that's not the same as telling them how they should do it. Using an issue to request access is only one of several options and some admins might not want use issues for that.

[chrisb13]

Thanks for entertaining my provocative questions @micaeljtoliveira :)

In the ACCESS-NRI org, there are less than 30 public repos that are not forks that don't have a license (out of 113). In the ACCESS-Community-Hub org, there are less than 10 repos without a license (out of 29). Not having a license is not necessarily an issue, as some repos do not store software and their content is not meant to be distributed.

So I guess the question then is, of the ~30 (ACCESS-NRI) and ~10 (ACCESS-Community-Hub) repos without a licence. Are there instances where it is problematic that they don't have one? And if so, are the risks big enough for us to worry about?

No, we are not okay with admins not advertising how people can request access, but that's not the same as telling them how they should do it. Using an issue to request access is only one of several options and some admins might not want use issues for that.

Yes I agree, it's a good point. At the same time, we sacrifice a consistent user experience and risk users not joining when it appears too onerous or different to what they've come to expect.

In general, I'm aware that both these kinds of checks take time and as I understand it, we don't currently have a process by which these things are routinely checked? This is why I'm trying to think of systematic ways of addressing the problem/reducing maintenance burden.

[ccarouge]

@chrisb13 :

So I guess the question then is, of the ~30 (ACCESS-NRI) and ~10 (ACCESS-Community-Hub) repos without a licence. Are there instances where it is problematic that they don't have one? And if so, are the risks big enough for us to worry about?

I'm not sure what risk you are referring to about the lack of licence. Having no licence means that whoever wants to use whatever is in the repository needs to ask the owner (admin in that case) whether they agree for that use. Having no licence does not mean people can go and pillage your stuff, that's actually the opposite. It means people can not use anything, for any use, without asking first. Full open access for anything is granted via a public domain licence and not a lack of licence.

[micaeljtoliveira]

Yes I agree, it's a good point. At the same time, we sacrifice a consistent user experience and risk users not joining when it appears too onerous or different to what they've come to expect.

The repositories in this org are managed mostly by the community and we don't want to have too many restrictions or requirements. One of the reasons why this org was created is precisely to have a place with less restrictions than the ACCESS-NRI org. The few restrictions and rules we are putting in place are mostly for security reasons, but otherwise we would prefer a "hands-off" approach.

In general, I'm aware that both these kinds of checks take time and as I understand it, we don't currently have a process by which these things are routinely checked? This is why I'm trying to think of systematic ways of addressing the problem/reducing maintenance burden.

We have plans to implement automated checks to the ACCESS-NRI repos (see ACCESS-NRI/.github#2, where I just added an item on licenses), but putting these things in place takes time.

In any case, it's good to have these questions raised. I'm happy to add some of them to the next Github management group meeting if you feel strongly about it.