E.g. MDN would be a good candidate

Not sure if there's a reason early work in this repo was BSD. Would seem to make more sense to have under MPL.

@fwenzel do you know the original reason? Or have objection to switching?

Description from @hwine via email:

• iterate over all repositories using api.github.com
• for each repository, attempt to retrieve the raw .gitattributes file
  • if it does not exist, that repo does not have LFS
  • if it does exist, examine contents to see if LFS attributes are there (this is the part I don't have figured out, but appears to be well documented in the LFS project)
• once it's known a given repo has LFS attributes:
  • clone the repo (a shallow clone may suffice)
  • execute git lfs ls-files <= gives counts & size

In general, the usage of the team management scripts is to add persons to teams so they can be contacted.

This means that "service accounts" should not be added. Which means that we need an exclusion list somewhere....

To Do:

• figure out where to store per organization
• update code to honor those lists

FYI: The following changes were made to this repository's wiki:

• Restricting write access to contributors is strongly encouraged. Please make that change (documentation).

These were made as the result of a recent automated defacement of publically writeable wikis.

For some reason (I found it once, but have since forgotten), repo2docker needs chardet installed as well. I installed repo2docker with pipx, so only had to manually install chardet once.

• Update docs to specify checking for chardet and install if needed. Docs lean towards folks installing in the virtualenv (which makes sense)
• also catch default branch is 'main'
• be more explicit about env variable names
• poetry instructions explicitly
• update docs for Makefile target changes

Add to the readme that credentials are expected to be found (by the GitHub3.py library) in .credentials in the project root (or script directory - not sure which is technically correct - it's in the .gitignore file).

Line 1: GitHub login to use
Line 2: API token in plain text

Rest of file ignored

Must have been a GitHub API change or something. admins.py is certainly not showing admins without 2FA is intended. It seems like it might be showing all members without 2FA?

The geckodriver no longer communicates properly with Firefox 64.0 in my setup.

My setup is ubuntu bionic on wsl with geckodriver 0.23.0 and cannonical Firefox 64.0

Script should report an error if it can not access an organization, either due to the org not existing or insufficient permissions.

This is wrong:

$ ./missing_2fa.py mozillaa
Congrats! All members have 2FA enabled in mozillaa!

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please see Mozilla-GitHub-Standards or email [email protected].

(Message COC001)

For folks in certain departments, it would be unusual for them not to have a GitHub login. At the same time, there are many exceptions, e.g. when developers only work on hg.m.o repositories. And many "that's okay" such as folks in non technical roles.

Currently, making the above distinction is left entirely to the human. Given the typical use case is to run this for a large number of folks (e.g. intern departure day), this leaves too much room for human error.

Enhancing the output to make a guess as to whether or not a GitHub login should have been found would be awesome.

The joys of scraping a web page :)

The pattern "${first_name}${last_name}" was not tried, and at least one person uses that pattern for their GitHub login.

In the removal directions it would be nice if, In addition to a URL for the removal of members from an org, there was at least a blurb about removing the user from the ghe_orgname_users people.m.o group, or even a link to https://people.mozilla.org/a/ghe_orgname_users/ --- e.g. ghe_mozilla_users and https://people.mozilla.org/a/ghe_mozilla_users/

Note that collaborators do not need such instructions.

The newer (1.0.0a2) develop branch versions of the github3.py package have a number of nice additions to support the modern Organization features.
However, there are a number of breaking changes that will require rework of some existing scripts.
Because of the compatibility issues, and that the upstream copy does not yet have a release date, I'll do this work on a new branch, which will include the github3.py code as a git subtree (manual method).

Any objections or concerns? Please post in this issue.

This article gives some tips on a more sophisticated approach to rate limit responses than currently deployed in some scripts.

There may be payoffs on the high-API-call scripts.

If the current user (or PAT) does not have permissions to close a PR, the script silently ignore it.

The script needs the repo:public scope to operate properly.

Some orgs don't use the same convention for the "all owner" or "all member" teams. Allow the user to specify something different.

See #81 for problems using repo2docker. In addition, it is very slow to build.

Our needs are simple, we don't need the features repo2docker provides.

Invitations to be an organization member can be cancelled, if not accepted, via ./manage_invitations.py.

It is not performing the same task for invitations to be a contributor. While these invitations are specific to a repository, they are displayed in the UI at https://github.com/orgs/<organization>/pending_collaborators.

While similar in concept, contributor invitations have a different response format.

Occasionally, a one-character account name can be suggested when checking for ACLs.

That's silly.

• figure out why that happened (not a bug, actually had [email protected] listed as address)
• add discard of any potentials shorter that minimum minimum password length for the 2 systems.

A goal for 2019 is to have every Mozilla repository on GitHub contain a standard code of conduct. (This applies to all Mozilla orgs, not just 'mozilla'.)

The current plan is to have tools that will:

• determine if a repository is compliant
• open an issue to bring into compliance
• open a PR to satisfy that issue (stretch goal)
• if the repo has a contributing.md file, generate a PR to prepend a local reference to the code of conduct file (stretch goal)

This is the master tracker issue for the work.

before revoking access for a login, it'd be a nice thing to do to look for any credentials that may be tied to that login.

In many cases, that is not observable (e.g. PAT in automation somewhere), but at least the following could be looked for:

• deploy keys authorized by login

Commit 61eb739 updated GitHub3.py to version 1.3.0, which broke User Search.ipynb. The notebook scripts should be updated.

Workaround until this is fixed:

1. activate venv
2. pip install -U git+https://github.com/hwine/github3.py.git@invitations
3. restart the kernel in the notebook
4. restore the current environment with pip install -r requirements.txt