The statuses depend on the development processes that we are working on. And I imitate the following statuses (specified for the cases of bug tracking) cf. https://bugs.freedesktop.org/page.cgi?id=fields.html#status Statuses for other development processes are as simple as you wrote; The default statuses on Redmine/ProjectChilly are fine to me. IMO, I think we should mention statuses + trackers + roles as a combination when speaking to development processes. By the way, please recommend me a good book on Redmine. (2011/02/17 0:30), Eric Davis wrote: Do your Issue Statuses help or hurt your workflow? Issue Statuses are used in Redmine to create a workflow for issues. In an optimized setup, the issues will move through the different statuses as they are worked on. The Issue Statuses I use for Little Stream Software have been optimized to be as simple as possible for single person business but also communicate where the issue is at to my clients. * Proposed - Someone has an idea for some work but isn't sure about it yet. * New/Approved - Both my client and I like the idea and agree on the budgets. * In Progress - I'm actively working on the issue. * Resolved - I've finished the issue and am waiting for client to sign off on it. (i.e. ready to be tested). * Closed - My client agrees the work is complete. I also use two issue statuses for when exceptions occur: * Declined - one of us decides the issue isn't needed but we want to document the conversation (instead of deleting the issue). * Feedback - someone has a question about the issue that prevents us from working on it This same workflow works for my Open Source plugins but in that case I act as the client and project manager. What issue statuses do you use? What have you found helpful?
Feb 17, 2011
The changing quality assurance paradigm All of the factors discussed in the previous section point to the need to end status quo quality assurance approaches and break down the barriers between all of the internal organizations that are instrumental to creating quality products. Leaving testing and quality assurance as an afterthought today is a ticking financial bomb.
Feb 14, 2011
関係各位: OK 各位： Không nên dùng độc lập mà viết ○○各位, ví dụ xxxチーム各位、SSS株式会社各位、 従業員各位 nên dùng trong trường hợp ngang hàng 関係者各位: Người Nhật dùng phổ biến, tuy nhiên, về mặt ngôn ngữ là không hợp lý vì có cả 者 và 位 (đồng nghĩa: đều có nghĩa là người) 各位 = 皆さん (nhẹ nhàng, informal hơn) 関係者各位様： tuy nhiên, về mặt ngôn ngữ là không hợp lý vì có cả 者 = 位 = 様 cùng nghĩa 各位殿,関係者各位殿: Tương tự trên, có 違和感 Google: 関係各位: 4 triệu hit -> có vẻ phổ biến hơn 関係者各位: 1 triệu hit 関係者各位様: 382K hit, trong đó rất nhiều hit không match hoàn toàn. Học tiếng Nhật: Sai cái sai giống y chang người Nhật (có lẽ nên như thế)