On Thu, 2 Sept 2021 at 13:40, Rich Bowen <rbo...@rcbowen.com> wrote: > > > > On 8/31/21 6:20 PM, sebb wrote: > >> It is not the goal of the tool to make editing source files easy or even > >> possible. It's a code analysis tool. Sure, it could link to the file in > >> the target repository, which may be what you're asking for. But it's not > >> intended to be a remediation tool. > > The easier you make it for projects, the more likely they are to use > > it and persuade others to do the same. > > > > I am only suggesting providing links to the Git repo files. > > Assuming that the tool has local checkouts of the repo, that should > > not be hard to do. > > At present not even the Github source repos listed at the head of the > > page are linked, and they are already URLs. > > > > I feel like this misses a pretty important aspect of this: It is *NOT* > easy to change these words. Any tools that we provide that encourage > people to simply s/foo/bar/ across a code base are going to create huge > problems.
That is NOT what I am suggesting. > Consider, for example, the doc that we've provided here: > https://inclusivenaming.org/language/implementation-path/ > > In particular, there are some word changes that BREAK EVERYTHING. > Encouraging people to do that via a simple click-and-commit interface > would be a HUGE disservice to those projects. That is NOT what I am suggesting. However I am suggesting providing a link to the source file. This is partly to make it easier to see the word in a bigger context (the pop-up display context is not always enough). But also to be able to manually edit the file e.g. in GitHub. In some cases it is pretty obvious how to make a fix; the tool should make it easy to do so if it can. Project members can then deal with the 'low-hanging fruit' and gradually get around to the harder changes. > Furthermore, those projects know far better than we do how to make > changes to their code. They know their CI systems. They know their > functional tests, their beta process, their deprecation cycle. It would > be presumptuous for us to provide a tool that says "click this button to > make all of these change!" (Yes, I am exaggerating for effect. Yes, I > know you're not suggesting that.) Then why bring it up? > Yes, OF COURSE we can improve the tool. Nobody is suggesting that it's a > perfect solution. But trying to make it into a remediation tool is not a > goal, and I seriously question whether it should be a goal, now or ever. > > As for "that should not be hard to do", I welcome your advice in how we > would do that, as I wasn't able to figure it out. It was, in fact, hard > to do. Note that this tool is used across many git solutions - it's not > *just* Github. Any solution must work for all possible Git hosting > solutions. No, it does *not* have to work for all Git hosting solutions. If it cannot be done, then don't provide a link. For GitHub it is easy if one has the branch name. The repo, filepath and line-number are already known to the Javascript code via JSON [1] The URL is then: <repo> - '.git'/blob/<branch>/<filepath>#L<line> For example: https://github.com/apache/www-site/blob/main/content/css/bootstrap.css#L4 The actual branch name is not currently provided to Javascript if it is the default, but that should not be too difficult either. [1] e.g. https://clc.diversity.apache.org/api/details.json?project=www-site.git&limit=1 > -- > Rich Bowen - rbo...@rcbowen.com > @rbowen
