I was adding the configuration file and received a warning on the config file itself. Ideally, this would ignore the config path.

On push events to default branch, the app could check for rules violations and open issues to alert and better prioritize making changes.

Open questions:

1. A single tracking issue for all rules or an issue per rule?
2. GitHub code search does not support regex. Is cloning the repo the only path? Some repositories have many commits and are very large.

As described in the-turing-way/the-turing-way#2343, the 'master' rule picks up the use in URLs, which may not be under the control of the author.

One solution is to modify the rule such that it excludes the condition whereby 'master' is preceded by '/'.

Should the checks run on private repositories? This requires adding the read permission for contents.

I'd like to submit some new terms to the project.

I think I can figure out how to add default terms from reading the code. I'm not sure how to add .yml files though.

If it helps, I'd be happy to write or review documentation for this, but I think I'd need some help to figure out how. Maybe a pull request, or some very rough guidance?

I was hoping that it would be possible to use a .github/in-solidarity.yml file inside an organization-wide .github repository, to have bot settings consistently applied across an org. That org-wide config file would contain _extends: ietf/terminology, to pick up the configuration from https://github.com/ietf/terminology/blob/main/.github/in-solidarity.yml.

That seems to fail, however, with an error that I don't know what to do about:

configuration is invalid: [
{
"instancePath": "",
"schemaPath": "#/additionalProperties",
"keyword": "additionalProperties",
"params": {
"additionalProperty": "_extends"
},
"message": "must NOT have additional properties"
}
]

Is this supposed to work? Am I doing this wrong somehow?

It is useful to know the version of the bot running and would allow understanding why a rule may not be present.

This rule will trigger itself if you use "human-hours" as a replacement for 'man-hours'

https://regexr.com/5ssh6

I have suddenly started to get "Could not load configuration" errors from the bot, but they contain no information on what might be the cause?

See for example https://github.com/NTAP/rfc8312bis/pull/77/checks

Is your feature request related to a problem? Please describe.
As an international community, many developers write in human languages other than English, and they may want to make sure that they are writing code and documentation with inclusive language in their native language. For instance, many popular libraries and frameworks need help translating documentation, and if someone sees a community-translated docs page as non-inclusive, that will damage the public reputation of a community.
Describe the solution you'd like
I have a good idea for how to implement a rule-set fit for i18n. A better way to structure the rule-set is to structure it with the following type signature:

export type Rules = {
    lang: string, // example: 'es-MX'
    defaultMessage: string, // a mustache template
    rules: {
        regex: (string | RegExp)[],
        level: Level,
        alternatives?: string[],
        message?: string;
    }[]
}[]

A list of fallback locales could be exported to cover similar locales. The matching algorithm would use a similar process as the current matching algorithm.

Regarding configuration, a list of specific locales would need to be provided by the user somehow, so In Solidarity does not trigger a false-positive for a language the user is not looking for; after all, a combination of text in one language could set off a false alarm from a rule for a totally different language.

Describe alternatives you've considered
Sure, developers could provide several different rules in their own languages, but it could cause unexpected results.
Additional context
This idea was inspired by i18next.init({...}).

The word "manageable" (and derivatives of) hits the "man" filter. See this for example.

Many (another word that would hit this filter) words that are listed probably need to appear in their entirety to be considered problematic. Consider using "\b" to match on word boundaries for those words. That might reduce false positives.

A naive first attempt at a pattern configuration could be the following.

export interface Pattern {
  description: string;
  regex: RegExp[];
  suggestions: string[];
  level: 'notice' | 'warning'  | 'failure';  // OctoKit doesn't export these
}

export interface Configuration {
    patterns: ('default' | 'extended' | Pattern)[];
}  

The pattern level would then rollup to the check level.

if (notice || warning ) => check conclusion is neutral
if (failure ) => check conclusion is failure

Would it be possible to enable this functionality by adding a YAML-based workflow to a repo, instead of needing to manually activate the bot for a repo?

The latter requires a manual step, while the former can be automated (we create and configure a lot of repos from scripts), and the manual step isn't scriptable.

Some orgs, like: GoogleAPIs & Google have a .github root repo for default configuration. It would be nice if in-solidarity-bot allowed configuration at the org level in addition to the repo level.

It would also be nice if it allowed configuration of wordlists and alternative suggestion.

The annotation messages could be improved with the contents of the line that caused the match. This will avoid having to go to each file to see the matches.

Perhaps:

Match Found
Please consider an alternative to master for the line containing const master = '1234'.

Annotation created at https://github.com/jpoehnelt/in-solidarity-bot/blob/main/src/annotate.ts#L61.

Additional reference: https://docs.github.com/en/rest/reference/checks#annotations-items.

🚨 The automated release from the main branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the main branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

The release 1.4.1 on branch main cannot be published as it is out of range.

Based on the releases published on other branches, only versions within the range >=1.4.0 <1.4.1 can be published from branch main.

The following commit is responsible for the invalid release:

• fix: publish to npm (#90) (902c5b0)

This commit should be moved to a valid branch with git merge or git cherry-pick and removed from branch main with git revert or git reset.

A valid branch could be beta.

See the workflow configuration documentation for more details.

Good luck with your project ✨

Your semantic-release bot 📦🚀

.

It can be confusing(#217) as to the source of the rules for third party contributors. The check summary could include a note on custom rules and the location for improvements.

The Checks API limits the number of annotations to a maximum of 50 per API request. To create more than 50 annotations, you have to make multiple requests to the Update a check run endpoint.

https://docs.github.com/en/free-pro-team@latest/rest/reference/checks#update-a-check-run

It would be great if the bot could recursively check a whole repository. Is that possible?

It would be nice if the custom annotation in .yml files also supported custom error text, and/or a URL.

that would allow folks or companies to include messages that are tailored to their use cases, and link out to canonical style guides for reference.

iiic the current lint warning would say something like: "Please consider an alternative to blacklist."

It would be nice if we could supplement the text so that it could say something like:

"See the style guide for more information: https://developers.google.com/style/word-list#master"

Or possibly even inline the style guide text.

"Please consider an alternative to blacklist.
Don't use blacklist, whitelist, and graylist. Instead, use more precise terms that are appropriate for your domain. See the style guide for more information: https://developers.google.com/style/word-list#master"