4 ms·
I work with a blind developer. We create personal feature branches, file a ticket for merge requests in our ticketing system, code review them directly in the t
by sn 7y ago
I work with a blind developer. We create personal feature branches, file a ticket for merge requests in our ticketing system, code review them directly in the ticket or via email, and then rebase the feature branch onto master. We don't, but you could plausibly do reviews directly in git via editing the file with any comments.
I've been wanting to try gerrit however: https://gerrit-review.googlesource.com/Documentation/dev-design.html#_accessibility_considerations https://gerrit-review.googlesource.com/Documentation/dev-des...
Please report back on whatever you end up doing.
One caution I have is that long term you should consider moving away from the gitlab tools if they are unable to fix accessibility concerns, so that everyone is on equal ground.
I also don't know how flexible he is on which browser or operating system he uses; he may want to try some others to see if they work any better.
- woodrowbarlow 7y agogerrit is great because rather than invent their own code review process, they've basically implemented a gui for the same underlying process that you'd use in the command-line (git-format-patch, email, and inline comments). this means you don't have to use gerrit to participate in gerrit-based code reviews. because of this, i would imagine that it is very friendly to accessibility tools for programmers.
- keufran 7y agoThanks for sharing. I'll do my best to do a follow-up.