Hi Daniel (and community manager),
word choices
As I leave individual words in individual commits, it’s fairly trivial for me to drop ones that are rejected by a project, and my tooling offers a place for such things (allow.txt enables one to supplement the dictionary, so I would just add a line with retriable and stop seeing it going forward).
real review
- Certainly. I’d be really disappointed if any large project took a large change like this without review.
Given its size, I would expect that to take a considerable period of time. - I’m happy to help to split the changes up. I can split by directory, file type, or change type (change type obviously gets a bit harder for larger change-sets).
- Obviously, I wouldn’t want to do that until the project decides it’s interested and suggests which means it would like the work split. (I’d start by updating the branch to some designated point, I presume
master, but you could suggest something else…)
- Obviously, I wouldn’t want to do that until the project decides it’s interested and suggests which means it would like the work split. (I’d start by updating the branch to some designated point, I presume
tooling
Indeed, it’s really best to deploy some CI for this purpose once a project accepts a PR like this so that the codebase doesn’t revert.
I’m actively developing a tool for this purpose:
I tend to offer the CI after the fact, of the form “if you liked these fixes, you could use this tool to keep your repository clean”, but I try not to push the CI too hard (and typically only offer it if there seems to be a real interest, as opposed to just a neutral response to a submission), which is why it isn’t a core part of my spelling fix offerings.
For mongodb, I initially omitted mention entirely because I was trying to follow the submission guidelines and given how large the change was, it seemed better to first get a sense of whether there was general interest in spelling fixes. – That’s sort of the stage of your current reply, trying to decide if it’s worth it at all.
I have a few features coming for future versions that will make it much easier to use (automatically recommending files to exclude / automatically skipping files, offering a way to update a user’s branch’s word lists)
You can see some of how the tool works here:
The configuration is pretty flexible, and I’m generally fairly responsive to feedback/input.
Fwiw, it’s becoming easier and easier for me to update change-sets like this one – I just updated apache/hive which is of the same size in terms of corrections.
lint
I did initially write a tool that integrated with Travis, but I’ve found that it’s a lot easier for most users if the output is straight in GitHub. If a project wants to work with me on adapting my tooling for some other system, I’m happy to try.