Redmine Tips - Do your Issue Statuses help or hurt your workflow?

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?

The changing quality assurance paradigm

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.

Cach dung 各位

関係各位: 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ế)