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

convert "here" links to useful snippets #331

Open
katrinleinweber opened this Issue Feb 14, 2018 · 6 comments

Comments

Projects
None yet
3 participants
@katrinleinweber
Collaborator

katrinleinweber commented Feb 14, 2018

Berkeley's Web Accessibility guide recommends against link texts like "Click here to read about our..." and suggests making them more descriptive: "..., read About Us". This helps screen reader users esp.

There are several instances of such links that could be converted accordingly.

@AnthonyDShaw

This comment has been minimized.

AnthonyDShaw commented Jun 11, 2018

I have begun converting links in my own fork to meet these standards and will push them once they are done, but I have noticed that there are many glossary links, where a single word or concept (like String) has a link to the glossary.
Is it suitable to leave these glossary links to stay as they are, or should they perhaps have an annotation? E.g. the String link might instead become the String (Glossary) link.

@katrinleinweber

This comment has been minimized.

Collaborator

katrinleinweber commented Jun 11, 2018

Hi Anthony, and thanks for working on this :-)

I suggest to leave glossary links as they are for now. I'm looking forward to reviewing your PR with the new link texts. Feel free to open it already. Cheers!

@AnthonyDShaw

This comment has been minimized.

AnthonyDShaw commented Jun 12, 2018

Hi @katrinleinweber , I was going to make a pull request, but after reading the guidelines "[SWC] would like substantial changes to be raised in an issue for input from maintainers before [I] work on a PR"

I am unsure if that counts in this context since I was going to make a pull request in response to your issue, but just in case I will instead link my own repository with the changes for commenting first. Or should I make a new issue instead?

https://github.com/AnthonyDShaw/r-novice-inflammation/tree/gh-pages/_episodes

@katrinleinweber

This comment has been minimized.

Collaborator

katrinleinweber commented Jun 12, 2018

The guideline seems a bit too timid, IMHO. Updating some phrases are not "substantial changes". Even if they were, without seeing the actual change suggestions, a discussion about them is a bit moot. The guideline rather intends to protect contributors from working on changes that are not welcomed by the maintainers.

Since a PR has built-in review features, I find that most effective. We have too many issues already. ;-)

PS: I did add some comments to your commits, so we can compare how reviewing there works, vs. in a PR.

@diyadas

This comment has been minimized.

Collaborator

diyadas commented Jun 12, 2018

Thanks for your work on this Anthony!

I just wanted to chime in and mention that it is the Rmd files that should be edited and committed, not markdown files directly, since the markdown is generated from the R markdown. I'll tweak the contribution guidelines a bit to make this (and PRs vs. issues) clearer.

@katrinleinweber

This comment has been minimized.

Collaborator

katrinleinweber commented Jun 12, 2018

Whoa, sorry for missing that! I thought #359 would prevent this from happening again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment