These users (both accounts are the same entity) has established a pattern of irresponsible behavior in the Arduino
Library Manager Registry repository. They continued this behavior even after the bot and human maintainer made
significant efforts to guide them to responsible use.
This user has established a pattern of irresponsible behavior in the Arduino Library Manager Registry repository. They
continued this behavior even after the bot and human maintainer made significant efforts to guide them to responsible
use.
This user has established a pattern of irresponsible behavior in the Arduino Library Manager Registry repository. They
continued this behavior even after the bot and human maintainer made significant efforts to guide them to responsible
use.
This user has established a pattern of irresponsible behavior in the Arduino Library Manager Registry repository. They
continued this behavior even after the bot and human maintainer made significant efforts to guide them to responsible
use.
`github.com/ajangrahmat` has established a pattern of irresponsible behavior in the Arduino Library Manager Registry
repository, related to the libraries of the associated organization `github.com/kelasrobot`. They continued this
behavior even after the bot and human maintainer made significant efforts to guide them to responsible use.
This user has established a pattern of irresponsible behavior in the Arduino Library Manager Registry repository. They
continued this behavior even after the bot and human maintainer made significant efforts to guide them to responsible
use.
This user has established a pattern of irresponsible behavior in the Arduino Library Manager Registry repository. They
continued this behavior even after the bot and human maintainer made significant efforts to guide them to responsible
use.
Background
----------
The Arduino Library Manager Registry repository receives thousands of pull requests from a large number of community
contributors. The great majority of these contributors behave in a responsible manner. Unfortunately this repository is
regularly the subject of irresponsible behavior. The small number of people who behave irresponsibly consume a
significant amount of the finite maintenance resources available for maintenance of Arduino's repositories.
Communication is always the first measure taken in these cases. This is done automatically by the "Manage PRs" workflow,
and then by the registry maintainer when it becomes clear that the user has disregarded the comments from the bot.
Unfortunately it is regularly the case that the user simply disregards all communication and continues their pattern of
irresponsible behavior unchecked.
Alternatives
------------
GitHub provides tools for dealing with harmful behavior:
- Report user
- Block user
Reporting a user is the appropriate measure in cases of malicious behavior, and the account is usually banned from the
site relatively quickly after a legitimate report is made. However, the irresponsible behavior in the registry
repository is not overtly malicious and so reporting the user in these cases would not be appropriate or effective.
At first glance, the block feature seems ideal. However, it can only be done at an organization-wide level, and by an
organization administrator. The repository maintainer is not an organization administrator, so this makes the feature
inconvenient to use. There is no sign of these users interacting with other repositories in the `arduino` organization,
and so there is no benefit to blocking them at organization scope. In addition, in order to make it more difficult to
circumvent the access restriction, we need the ability to block requests for libraries owned by an entity who has
established a pattern of irresponsible behavior, regardless of which user submits the request.
So the tools provided by GitHub are not suitable and a bespoke system must be implemented.
Access Levels
-------------
Allow: the user may submit requests for any library, even if registry privileges have been revoked for the owner of the
library's repository. This access level will only be granted to registry maintainers, in order to allow them to make
exceptions for specific libraries owned by an entity whose privileges have been revoked.
Default: the user may submit requests for any library, unless registry privileges have been revoked for the owner of the
library's repository.
Deny: the user may not submit requests. Requests from users with "default" access level for any library repository owned
by the entity (user or organization) are denied.
In cases where a request is declined due to revocation of Library Manager Registry privileges, the "Manage PRs" workflow
will automatically make an explanatory comment, including a link that provides more details about the cause of the
revocation. It will also close the PR in the case where it is not possible for the requester to resolve the problem:
* The requester's Library Manager Registry privileges have been revoked
**-OR-**
* The owners of all library repositories which are the subject of the request have lost Library Manager Registry
privileges.
The "Manage PRs" GitHub Actions workflow uses a command line tool named "library-registry-submission-parser" to parse
the pull requests submitted to this repository.
A new version of "library-registry-submission-parser" has been released, and so the version specified in the workflow
for use is hereby updated.
Two additional mandatory flags have been added to the command line interface of library-registry-submission-parser, so
these flags are added to the invocation, and an access control configuration file added to the repository as required
for use with the new `--accesslist` flag. To start, the access control configuration file is left empty, giving all
users default access privileges as before. The workflow will be adjusted to take advantage of the newly added access
control capabilities of library-registry-submission-parser in a separate commit.
Since it is intuitive and commonly used, the default behavior of the actions/checkout GitHub Actions action when a
workflow is triggered the "pull_request" or "push" events is well understood by any workflow maintainer. However, the
default behavior of the action when the workflow is triggered by a "pull_request_target" or "issue_comment" event (as is
the case for the "Manage PRs" workflow) is not obvious and less well known since these events are more rarely used.
It is important for the maintainer to understand which Git ref will be checked out by the actions/checkout action steps
in the "Manage PRs" workflow. Adding an explanatory comment will help to ensure they have this understanding.
