isobar-us/code-standards

Idea: Pull most links out to separate section

rcherny opened this issue · 5 comments

I'm concerned about link rot and things like that. Also, in terms of resources, they are fluid and a dime a dozen (sometimes).

Effectively I'm thinking that we start to get really careful about what we allow as a hard coded link in the standards doc going forward.

I'm thinking that perhaps the things like the Appendix or possibly even references or sources for each section in the document be pulled out into pages similar to this:

https://github.com/isobar-idev/code-standards/wiki/Useful-Links-and-Resources

Not in one page, and probably Markdown pages in an actual Repo, since Github Wikis, as I understand it, are source control challenged.

Just a thought. We might have a "useful resources" link at the end of each section, or something along those lines.

My reasoning is that links come and go, as do valuable resources, but the Standards Doc content should be a little more vetted, a little more persistant, even though it will continue (hopefully, but let's be realistic) to be a living document.

I'd want the resources to be even more fluid and easy to change. Also, it will drive traffic to our Github.

Thoughts? Opinions? Feelings? Reactions? Good? Bad? Indifferent?

If using markdown is the plan, then the method of linking which can be done in it where you refer to a link which can be listed at the bottom of the content, eg: psuedo but you should get it

This is (link1)[1] and this link is (link2)[2].
More content etc...

[1]url here
[2]url here

This could work, similarly to something like a wikipedia page where the links may be all listed in the code anyways in one place, but the links are actually linked text in the content. Hope this makes sense.

I support the idea of having a separate "References/Materials" section for most links.

+1 @jaredwilli
I would consider this as one of the arguments for content in markdown.

One of the more recent comments here (internally) was to have more persistent link content obviously be allowed. Things that might be considered persistent would be:

  • specs
  • things like MDN
  • ...?

I worry about linking directly to specs, as so often the spec and the actual browser implementations differ. Not to mention that w3c spec pages are horrific to read.

I've investigated some options that could help us deal with link rot problem, logged in #123

Regardless of whether we pull links out into a separate section, or leave them inline, an automated link-checker could be useful.

I suspect we won't be doing this. Ended up with links in there anyways, as long as we can curate the better going forwards...