Pre-Github, projects would need to fire-up their own Bugzilla or Fogbugz instances, set-up all the project tracking criteria (areas, iterations, severity, etc).
But unstructured label tags seem to work surprisingly well in practice: projects that would have otherwise demanded 20+ fields for work-item tracking now seem fine with issue labels.
Bingo. It surprises a lot of people how little you need to be successful if everyone's on the same page. I've worked places that had thousands (yeah, thousands) of apps, dozens or hundreds of millions line of code, and had little to no issues with collaboration (oh, they thought they did, but compared to almost any other company, they really didn't), and process/tooling involved github issues, markdown files for docs and little else. Sometimes they'd toss in trello in the mix and that's about it.
You definitely can do better, but as a baseline, it's more than enough.
Needing to put 20+ tags IMO is a hint that something about the process is wrong ... I'd love to hear some ideas about what could _possibly_ be enabled by having 20+ tags on a given work item. What workflow could possibly need that level of detail?
I agree, but that relates to the original complains about Bugzilla users who required 20+ fields. I encountered 3-5 fields maximum and usually they were optional and I would prefer form with 3-5 proper fields to arbitrary tag string.
> Pre-Github, projects would need to fire-up their own Bugzilla or Fogbugz instances, set-up all the project tracking criteria (areas, iterations, severity, etc).
So a ready-made setup at an existing service open to multiple projects would work. I guess that's what Sourceforge was.
Sourceforge stopped innovating after they started offering SVN as an alternative to CVS (!!), everything since then was about monetising their audience (e.g. spyware injected into binary installers) and wrecking the quality of the user-experience with aggressive advertising.
Sourceforge could have been github, but when a company turns on its users while failing to deliver value it won’t last.
Because git is decentralised it means all the git-hosting services become commodity, and we’ve learned that having the best UX keeps people around - even if your service is commodity, so I expect this basis will ensure GitHub (now part of Microsoft) will stay in the community’s good-graces.
Pre-Github, projects would need to fire-up their own Bugzilla or Fogbugz instances, set-up all the project tracking criteria (areas, iterations, severity, etc).
But unstructured label tags seem to work surprisingly well in practice: projects that would have otherwise demanded 20+ fields for work-item tracking now seem fine with issue labels.