Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idea: file issues on the repositories with issues #74

Open
foolip opened this issue Dec 11, 2019 · 7 comments
Open

Idea: file issues on the repositories with issues #74

foolip opened this issue Dec 11, 2019 · 7 comments

Comments

@foolip
Copy link
Member

foolip commented Dec 11, 2019

https://w3c.github.io/validate-repos/report.html lists all the problems detected, but it requires some W3C staff to drive down, the people who work on a repo will never notice these problems unless poked.

It would be fairly straightforward to have a bot file issues on the repos with errors and provide as much detail as possible for how to resolve in those issues. Keeping things in a good state would then be a matter of a GitHub search for those issues rather than looking at https://w3c.github.io/validate-repos/report.html.

@plehegar @dontcallmedom do you think this would be a big improvement, or not really solving a real problem you have?

@dontcallmedom
Copy link
Member

@foolip that would indeed be a more scalable way to manage this. Before we can do that, we would need to classify:

  • which error reports are fully reliable (some aren't yet, e.g. the comparison of the different "rec-track" status across tools)
  • which errors reports can be meaningfully acted upon by repo owners (not all of them are either - e.g. when a repo is marked as rec-track in the repo manager, it takes a bit of wizardry to fix that at the moment)

Have you thought about how we would avoid duplicating issue reports if we were to create them automatically

@plehegar
Copy link
Member

I looked around a bit. I concur with @dontcallmedom . In addition, if we're going to file issues, let's make sure to assign them to whoever is listed in the contacts. (and we should double checks that the current contacts are up-to-date before doing so).

@foolip
Copy link
Member Author

foolip commented Dec 13, 2019

As you point out, not all issues are with the state of the repo itself, and those probably don't make sense to file as issues on the repo. At a quick glance, I think the errors checked in this view are ones that can be fixed on the repo itself:
https://w3c.github.io/validate-repos/report.html?filter=now3cjson%2Cinvalidw3cjson%2Cincompletew3cjson%2Cunprotectedbranch%2Cunprotectedbranchforadmin%2Cnorequiredreview%2Cnocontributing%2Cmissingashnazghook%2Cnolicense%2Cnocodeofconduct%2Cinvalidlicense%2Cnoreadme

To avoid duplicated, a unique bot account for this purpose should be used, and one can either make sure to never file issues with the same title as an existing open one, or encode some information hidden in the issue bodies.

@plehegar
Copy link
Member

If we're capable to raise issues for missing *.md, aren't we capable of raising pull requests?
For branch protections, shouldn't we activate those automatically?

@foolip
Copy link
Member Author

foolip commented Dec 13, 2019

Sending PRs or otherwise just fixing the problem where it doesn't require any human oversight is definitely doable. I haven't done the latter, but @dontcallmedom and I have worked together on automatically sending PRs in https://github.com/tidoust/reffy-reports/tree/master/wpt-sync, in a way that avoids duplicates.

@ollie-iterators
Copy link

Is there a reason why this is not implemented yet? I would think that something that would help the many repositories that w3c has be better able to be maintained would be an important thing to work on.

@dontcallmedom
Copy link
Member

Is there a reason why this is not implemented yet? I would think that something that would help the many repositories that w3c has be better able to be maintained would be an important thing to work on.

note that the tool is still being used "manually" to identify and correct issues as they arise; automatically filing issues would be first and foremost a way to spread that maintenance burden.

I'll note separately that I've experimented with semi-automatic filing of issues in a different project https://github.com/w3c/strudy/blob/main/.github/workflows/file-issue-for-review.yml

dontcallmedom added a commit that referenced this issue Sep 4, 2023
…eport

only for ill-formed and invalid w3c.json at this time. Part of #74
dontcallmedom added a commit that referenced this issue Sep 4, 2023
…eport

only for ill-formed and invalid w3c.json at this time. Part of #74
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants