New GitHub repo feature: - Add topic

[Gormartsen]

We can use this feature to at least separate repos on github by:

• layout
• module
• theme

Here is an example:

[Al-Rozhkov]

@Gormartsen, do you know why some repos don't have this feature?

There is view_mode_selector repo, it was ported by me. And I can't add topic to it.

But looks like I can add topics to new repos.

[Gormartsen]

@Al-Rozhkov when you was transfering this module, did you add Authors group as admin and Security as write ?

I assume that's a reason, aldo I am not able to check it. I don't have admin permission on backdrop-contrib organization.

@klonos Do you have it? Can you check that Authors team is admin to this project?

[klonos]

@Al-Rozhkov seems to be a permissions issue. Notice how on the first repo screenshot (view_mode_selector) there is no "Settings" tab available to the top, while on the second repo there is?

[klonos]

@Gormartsen ...you beat me to it 😄. Yes, that is the issue.

[Gormartsen]

@klonos Can you fix that? Do you have enough permission on backdrop-contrib ?

[klonos]

Yep, on to it...

[Gormartsen]

@klonos Also there is few more projects like this. I randomly selected repos and I don't see 'Settings' page 😿

[klonos]

Done:

• removed @Al-Rozhkov from the collaborators list (had only "write" permission)
• added the "Authors" group with "admin" permission (@Al-Rozhkov is a member of this group)

@Al-Rozhkov can you please check now?

@Gormartsen is there a way to get a list of such projects?

[klonos]

@Gormartsen is there a way to get a list of such projects?

...and more importantly, is there a way to automate this? ...like adding a permission check and auto-fixing repositories.

[Gormartsen]

@klonos I assume we are missing this keypoint in TODO or somewhat.

I was using this doc when I was doing my first contrib: https://tag1consulting.com/blog/how-maintain-contrib-modules-drupal-and-backdrop-same-time-part-2

@klonos: is there a way to get a list of such projects?

Checking

[klonos]

Also in https://github.com/organizations/backdrop-contrib/settings/member_privileges I see that the default permission for repositories is set to "write". So, not sure if we are abusing the permissions here or if we should change the default to "admin" so this does not happen to repos transferred.

@quicksketch? @jenlampton? @serundeputy?

[Al-Rozhkov]

Yes, it works now. But why I have such permissions on Insert repo? I'm not a maintainer.

[Gormartsen]

@Al-Rozhkov it is because backdrop-contrib rules are different. We rely on respect instead of permission. Every backdrop-contrib developer has access to each repo and able to push changes

[klonos]

@Al-Rozhkov What @Gormartsen said ^^ ...R.E.S.P.E.C.T ❤️

[Al-Rozhkov]

It is such an honor for me to be a part of the community 😊 I ❤️ Backdrop

[Gormartsen]

@klonos

I know how to download all repos list with JSON format. So you can addopt it to find strings like this:

    "permissions": {
      "admin": false,
      "push": true,
      "pull": true
    }

But let's wait for @quicksketch @jenlampton @serundeputy answer about admin level, maybe I am missing some latest changes on default policy for Authors.

[Al-Rozhkov]

Also it would be usefull to have categories or tags for modules. Just like on drupal.org. I don't see any issue in backdropcms.org issue queue and here. Should we create one?

[jenlampton]

I see that the default permission for repositories is set to "write".

Here's what I'd like to see (I'm not sure if this is possble in a GitHub world, but ...)

WRITE - Member role

• Every member of the contib group has WRITE permissions on all projects in the contrib group.
• The security team should have WRITE permissions on all projects (but since this is the same for all contrib group members, nothing special needs to be done)

ADMIN - Member role

• When I am creating a new project in the group, or moving an existing project into the group, I automatically retain ADMIN permissions on that project.

ADMIN - Owner role

• Some high level admins (like @klonos) have ADMIN on all projects.

[Gormartsen]

@jenlampton It is possible to make so, but with extra coding. We defently need to react on events like "repo created" and add permissions like you mentioned.

here is some helpful doc on this topic: https://help.github.com/articles/repository-permission-levels-for-an-organization/

[jenlampton]

Hm, I don't see any way to tie a member to a project once the project is moved to the group.

[klonos]

Also it would be usefull to have categories or tags for modules. Just like on drupal.org.

Been asked before: https://github.com/backdrop-ops/backdropcms.org/issues/181 ...it's on @Gormartsen to-do list (a long one) 😄

[klonos]

...isn't a good thing that you have someone like me to follow ALL issues and remember (as best as a human can) when things have been filed as issues before ?

[jenlampton]

...isn't a good thing that you have someone like me to follow ALL issues and remember (as best as a human can) when things have been filed as issues before ?

YOU HAVE NO IDEA :) :) :) :) :) :) :) :) :)

[Gormartsen]

Hm, I don't see any way to tie a member to a project once the project is moved to the group.

Collaborators, but user should be the member of the backdrop-contrib org. example:

[klonos]

Hm, I don't see any way to tie a member to a project once the project is moved to the group.

https://github.com/backdrop-contrib/nodequeue/settings/collaboration

...was about to post a screenshot, but what @Gormartsen says 😄

[klonos]

...some projects have the original porter listed as collaborator (with either admin or write permission) instead of the "Authors" team with admin permission.

[klonos]

...instead of the "Authors" team with admin permission.

Which is what I'm asking if its the "correct" setting. ??

[Gormartsen]

Which is what I'm asking if its the "correct" setting. ??

I see only one side effect - not respectful user decided to delete repos and slam the door.

But I would better setup backups and use this ability as a honeypot for not good guys.

[jenlampton]

...some projects have the original porter listed as collaborator (with either admin or write permission)

This is correct, but should be ADMIN not write.

instead of the "Authors" team with admin permission.

This is incorrect, Authors team should have "WRITE" permission only.

I see only one side effect - not respectful user decided to delete repos and slam the door. But I would better setup backups and use this ability as a honeypot for not good guys.

That's a pretty big risk... giving everyone write access creates enough of a honeypot for the bad guys IMHO.

[klonos]

...some projects have the original porter listed as collaborator (with either admin or write permission)

This is correct, but should be ADMIN not write.

instead of the "Authors" team with admin permission.

This is incorrect, Authors team should have "WRITE" permission only.

There's heaps of repos to be fixed then and I think it will be a pretty big undertaking to do this manually. @Gormartsen is there a way to do this en mass?

[Al-Rozhkov]

Been asked before: backdrop-ops/backdropcms.org#181 ...it's on @Gormartsen to-do list (a long one) :smile:

I have read issue you mentioned @klonos. As I understand it is about GitHub labels (feature-request, bug...). What I mean by "categories or tags for modules" is a type of functionality provided by module: Administration, Content, Fields, File Managment, etc.

There are a lot of modules in Backdrop contrib world and keep growing. Sometimes you know what kind of funtionality you need, but can't pick a module by name, so you have to read all descriptions. It would be great to go to particular category and keep looking.

[klonos]

@Al-Rozhkov ah, then no. Please feel free to file a separate issue for that in backdrop-ops and give it the GitHub automation label ...and assign it to @Gormartsen 😄

[klonos]

I see only one side effect - not respectful user decided to delete repos and slam the door.

Yes, this has been discussed before. It was a risk that we said we'd have to live with be cause we did not have the time/resources to implement things otherwise. Perhaps we should get that back on the table and see if there's something we can do about it. @jenlampton a topic worth bringing up during the dev meeting tomorrow perhaps?

[jenlampton]

Please feel free to file a separate issue for that ...

But wait, we have three of those:

• https://github.com/backdrop/backdrop-issues/issues/37
• https://github.com/backdrop/backdrop-issues/issues/1543
• https://github.com/backdrop-ops/backdropcms.org/issues/100

[serundeputy]

I think we can lock down certain branches; so like for drush repo I set the main branch so that only the maintainers can commit to it.

This could be bypassed but it can be used to help mitigate access.

[jenlampton]

It was a risk that we said we'd have to live with be cause we did not have the time/resources to implement things otherwise.

I think that was before we have the permissions we have now. The current solution works, so I don't think we need to risk anything anymore. (I've just gone through and updated a handful of my repos.)

[klonos]

@jenlampton if I have this right, these issues involve either how projects are grouped/filtered by in the product (using the project browser or the modules listing page in the admin UI) or how we could have more info added to .info files so that they can be sorted/filtered by properly in b.org. @Al-Rozhkov was referring to helping people searching on GitHub. Right @Al-Rozhkov ??

[klonos]

I've just gone through and updated a handful of my repos.

Yep, but this should be automated upon project transfer to backdrop-contrib if possible. Either that, or have a cron job run and "sanitize" permissions. Namely name sure that the "Authors" group is added to the teams of each (every) project and that it has "write" permission.

[jenlampton]

but this should be automated upon project transfer to backdrop-contrib if possible. Either that, or have a cron job run and "sanitize" permissions. Namely name sure that the "Authors" group is added to the teams of each project and that it has "write" permission.

Yes, and we should be sure that the creator is added to the collaborators group with "Admin" permission, too.

@Al-Rozhkov was referring to helping people searching on GitHub.

Oh. Well people should really be searching on backdropcms.org. GitHub is not a good place for finding anything :) I'd prefer we focus our efforts there.

[Gormartsen]

@klonos do you need a list of repos where Author group has access "admin", right ?

[Al-Rozhkov]

I dove into those issues... And I must admit Project Browser going to be great tool. I used to look for modules in backdrop-contrib, because module can be fully functional but not available on backdropcms.org. It happens when maintainer doesn't create release.

Ah, well people should really be searching on backdropcms.org.

I agree, b.org and Project Browser are better places for finding stuff.

[docwilmot]

Side note: re https://github.com/backdrop/backdrop-issues/issues/37, is that really a 2.x issue? It wouldnt break any APIs, its just adding new metadata to .info files and rearranging the modules page. Curious?

[jenlampton]

@docwilmot good point, maybe it depends on how much we need to do to the modules page? We should re-evaluate once we have a PR. We could add the tags in 1.x, even if full support comes later.

[docwilmot]

We should re-evaluate once we have a PR

https://github.com/backdrop/backdrop/pull/900 :smile:

[klonos]

@Gormartsen Yes, plus:

• a list where nobody is listed as collaborator
• a list where collaborators have "write" instead of "admin"

[Gormartsen]

@klonos

• [x] 'Authors' has "admin" permission I used not straight forward login to receive a list where 'Authors' has "admin " permission. Keep it in mind, please. There is could be some mistakes. https://gist.github.com/Gormartsen/7fa0bdaabf279b59961c9910cb142a57
• [x] nobody listed as collaborator https://gist.github.com/Gormartsen/a467a9b25ed09df83c688ace124420f6
• [ ] where collaborators have "write" instead of "admin" this one actually a list of repos where collaborators exists but permission is NOT admin. Please confirm this list, I do't have permission to visually confirm it. https://gist.github.com/Gormartsen/66245da5670644c650bf56a0cbc1ccaf

[Al-Rozhkov]

@klonos I have same permissions issue as here https://github.com/backdrop-ops/contrib/issues/214#issuecomment-293600864. I just transfered https://github.com/backdrop-contrib/feeds_xpathparser repo with enabled Authors and Security teams checkboxes. And now I don't see settings tab on repo page.

I just wanted to make 1.x-1.x branch default and add "module" topic. I can't do this because I don't have permissions. Sorry for bothering you. What did I do wrong during transfering process?

[jenlampton]

@Al-Rozhkov I've made you an admin for https://github.com/backdrop-contrib/feeds_xpathparser, Also, you don't need to manually add the security team because those folks are all Authors ;)

[Al-Rozhkov]

@jenlampton thank you! Was it my mistake during transfering process? How to avoid bothering you in future?

[jenlampton]

No @Al-Rozhkov it was not your mistake. We need to automate the process of adding the project-creators as "collaborators" with" admin" access. I don't think there's a way for you to do that yourself (?)