Migrate issues from Docs repo to Stubs repo

[DanRathbun]

This tool runs under Ruby (uses OctoKit):

https://github.com/trbritt/github-issue-migrate

[thomthom]

Maybe this one? https://github-issue-mover.appspot.com/

[DanRathbun]

We may not need this as by the time we get to it, most will be manually migrated and closed.
I suggested to Jim that all the "=" issues be consolidated into one stubs issue.

[DanRathbun]

@jimfoltz: For example, today I am going to open an issue titled "Geom::PolygonMesh" to declare my intent to begin work on that documentation.

I'd prefer we could set the assign flag.
Well with the lack of ability to self assign, perhaps just put a bold note at the very top:
@thomthom Assign to: _your@name_
blank line
Issue Description ...

[DanRathbun]

This list below came from thread "Confusion over discussions".

I had crossed out incorrect lines, and added some thoughts in bold, concerning the use of the "ruby-api-docs" html output repo.

But that morphed it into being more about migrating issues, and the use of the output "serving" repository.

So here it is:

---

1. 1st problem is the HTML "docs" repo. This repo doesn't do anyone much good at all. (Unless they wish to just copy all the pages to their local drive. But, then the pages could be packaged up in a zip.)
But this was before the stubs were setup to be the "working repo" for the API documentation. So most the doc bug issues there need to be migrated to the ruby-api-stubs repo.

As noted by @thomthom, the online docs are served right from GitHub.
(I thought they were copied to a Trimble server. My Bad!)

2. Anything discussing, or promoting ideas for the styling and functionality of the http://ruby.sketchup.com/ needs to be migrated to the sketchup-yard-template repo.

3. And then the ruby-api-docs repo removed.

Okay, so the docs repo is needed.

Perhaps the people who are not familiar with YARD syntax, nor GitHub protocol, can log issues in the docs repo. They will have no idea which (or why) of the other two repo (projects) that the issue, bug, or feature request applies to. This is understandable. So it is a buffer tracker.

Then one of the stubs or template repo contributors can migrate it, or rewrite it in the proper form as a specific stub change order (or orders if neccessary,) over in the appropriate "parent" repo.

Nitty implementation details can be debated in the 2 "parent" repos, where the doc consumers would likely not read, nor understand the YARD internals discussed if they did.

[thomthom]

I'd prefer we could set the assign flag.

Just suggested in #15 that one could start off with a PR - which creates an issue as well. That way one see who is working on something and what is being done. Just a thought.

[DanRathbun]

I assumed they were separate as they have separate member links at the top of every page.
And then separate tabs at the top of the repo.
But I'll try it and see.

[DanRathbun]

Okay, @thomthom, if you migrated all issue reports that needed to be moved you can go ahead and close this.