Having to create issues-only repositories seems like a sign that one may be using the wrong tool. But the simplicity of GitHub Issues, and the fact that most issues on my plate are related to a particular repo, makes it tempting.
> Having to create issues-only repositories seems like a sign that one may be using the wrong tool.
JIRA is a pile of bolted-on features, and no one has ever measured what is essential to project management, so this point strikes me as sort of an ad populum than an argument that JIRA or whatever is more fit for some PM task than Github Issues.
This is what kills me about software project management, at least in Enterprise where I work: its about people consistently communicating to one another; that's it, lest there's something else we can extract as somehow more primordial. Somehow people consistently communicating over a topic has been reified to the point that we mistake the reified things for the thing-in-itself.
You don't really need this, though. Github has a project board, too, and it's ... pretty good!
My gig is still in Trello-land and I'd like to move away from it but companies have a tendency to include biz folks in Trello whereas Github is scary tech world to a lot of them.
I signed up within the first few hours of beta announcement. Still haven't got it.
I understand they want to get it "right" before opening up to the majority, but project management isn't something a business can sit and wait. People have to use some other tool in the mean time, and once having invested time and effort they won't switch back easily.
I find it to be unusable for projects of any decent size. There's pretty much zero visibility on what everybody else is doing, discussions are hard to use when they go over five comments (for example, you can't easily binary-search a large discussion with Home/End or my favorite vim-like navigation plugin, because you don't have the full page right away and it loads a few comments at a time). It's very JS-heavy and writes multiple gigabytes of data to localStorage every hour (which wears down my SSD needlessly) — the only web application I've ever seen doing that. I can go on.
> Having to create issues-only repositories seems like a sign that one may be using the wrong tool.
Use it to track white papers, project planning documents, a project-wide wiki, et c., if you want to feel like it's for more than just issues. Though having an issues-only project doesn't seem worse to me than using any other stand-alone issue tracker, separate from GH.
I don't see why that's a sign of the wrong tool: if it's OK to use a GitHub repo for code and not for issues, why not use one for issues and not for code?
I drop a single README.md in the root of the repo that links to the issues and leave it at that.
