[Bug 553285] All our Github organization should include of fork of /eclipse/.github

Bugzilla Link	553285
Status	NEW
Importance	P3 normal
Reported	Nov 20, 2019 14:00 EDT
Modified	Nov 11, 2021 16:59 EDT

Description

Similar to what I did with, https://github.com/jakartaee/.github we should fork https://github.com/eclipse/.github on all our organization such as eclipse-ee4j

I don't have access to fork or create repos for these project organizations.

Webmaster, can you create them and grant me access to these new repos? I will be happy to take on the responsibility for updating them!

added Bugzilla legacy ~16280 labels

Should this not be done via api?

I don't know how many organizations we have, but it's supposed to be one org per project. Making org-wide changes could be onerous if done manually.

The other option is to put the onus on our projects to do this.

(In reply to Denis Roy from comment #1)

Should this not be done via api?

I was planning on automating the process for updating these repos by leveraging data from our Api but I don't believe you can create an organization via Github API unless we move to GitHub enterprise.

Since I believe that creating a new org is a manual process, I was thinking that we should require a fork of https://github.com/eclipse/.github when we create a new org.

I don't know how many organizations we have, but it's supposed to be one org
per project. Making org-wide changes could be onerous if done manually.

I believe that the eclipsewebmaster account is an admin on all our organization. You should be able to see how many org that we own on the profile page of the eclipsewebmaster github account.

Otherwise, I should be able to query the PMI to get a list of all our organizations.

(In reply to Denis Roy from comment #2)

The other option is to put the onus on our projects to do this.

Can projects create new repositories under their organization?

For more information about this issue:
https://github.com/jakartaee/specifications/pull/125

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.

What's the action item here, and what's the problem being solved?

Action item:

Fork a copy of https://github.com/eclipse/.github to each org.

The problem being solved:

The .github repository acts as a fallback for all of your repositories that don't have an actual .github directory with issue templates and other community health files such as https://github.com/eclipse/.github/blob/master/CODE_OF_CONDUCT.md and https://github.com/eclipse/.github/blob/master/LICENSE

Should we do this?

If we do, we need a strategy for keeping these forks up-to-date. For example, if we publish a new version of the CoC, we will need to create a script that pushed the update to all the forks. This will need to be done by an account with access

Alternative solution:

1. We put the onus on our project as you suggested: #460 (comment 413418)

2. We make a feature request asking our sync script to create the forks using GitHub API if we detect that the .github repo is not there: https://docs.github.com/en/rest/repos/forks#create-a-fork

If we do option #2 (closed), we still need to think about a strategy for keeping this fork up-to-date.

@netomi can we leverage Otterdog to get this done?

It could be used for that purpose, but I question if forking this specific .github repo would be useful. The only file that is relevant for all projects is the code of conduct imho.

You could setup a template repo like we have done for the .eclipsefdn, and update the default config for otterdog to create that for each organization if it does not yet exist:

https://github.com/EclipseFdn/.eclipsefdn-template

There would also be support for templating where you can replace things like the project name or GitHub organization in the file contents of the template repo.

We have defined it like that here:

https://github.com/EclipseFdn/otterdog-defaults/blob/main/otterdog-defaults.libsonnet#L356

Thanks @netomi,

I created this issue more than 4 years ago. I think the motivation was to ensure default such as our Code of Conduct would be available if the project did not include them in their repos.

However, if there is now a better way to do this, we should definitely do that rather that trying to implement the solution that I originally suggested!