Why have I been so quiet here? I've been hard at work reviewing the 150+ issues which have already been placed in the issue tracker.
Thanks to some previous discussion from people who actually know what they're doing, I was able to cobble together an issue tracker workflow. This is a checklist which any team member can use to know basics like:
- What's new?
- What's on my todo list?
What are my priorities?
This system can handle all of the issues we already have in there, and anything I have dreamed up so far. I hope that the system will work long into the future. It's pretty simple, even though the documentation is a big fat TL;DR. I'll end up making some screencasts just to help remove the intimidation of learning all of this.
We already have all package requests being piped through the issue tracker, and I hope that every single package gets tracked in this way.
This is SO not what I wanted to do, but because all of this was blocking my triaging docs-related tasks, I needed to step up to get it all done.
Now it's looking more like a communication and documentation type of thing, so it's getting more comfortable for me to work on this stuff.
I'm already finding issues with Flyspray. It's probable that some of my issues are because of my ignorance of Flyspray itself, but I feel like it's equally likely that Flyspray has attempted to stay fairly general and industry-average, and our particular usage is not industry-average. The QA and workflow methods that are done out there in the real world are real crap, so that wouldn't shock me at all.
I think that some of the concerns I have will be solved by one of our teammates hacking out an issue-submission script.
At any rate, this has been a hell of a lot of work but it'll be worth it. A proper issue tracker as well as proper QA and workflow processes are absolutely essential to the longevity of a project. They are what take a project from a simple benevolent dictator hobby project to an actual big and organized team project.