Well cool then. Sounds like you have a solution in mind. Thanks for figuring this out.
Shosholoza, Rich On Thu, Sep 2, 2021, 17:21 sebb <seb...@gmail.com> wrote: > 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 >
