Mod Removes Wiki by World Engineer
7 issue tracking += http://en.wikipedia.org/wiki/Issue_tracking_system "what's this?"
source | link

Tell them this is only an amateurish name for the Root Cause field used by professionals (when issue tracker does not have dedicated field, one can use comments for that).

Search the web for something like software bug root cause analysis, there are plenty of resources to justify this reasoning 1, 2, 3, 4, ....


...a root cause for a defect is not always a single developer (which is the main point of this field)...

That's exactly why "root cause" is professional while "person to blame" is amateurish. Personal accountability is great, but there are cases when it simply lays "outside" of the dev team.

Tell your boss when there is a single developer to blame, root cause field will definitely cover that ("coding mistake made by Bob in commit 1234, missed by Jim in review 567"). The point of using the term root cause is to cover cases like that, along with cases that go out of the scope of the dev team.

For example, if the bug has been caused by faulty hardware (with the person to blame being someone outside of the team who purchased and tested it), the root cause field allows for covering that, while "single developer to blame" would simply break the issue trackingissue tracking flow.

The same applies to other bugs caused by someone outside of the dev team - tester errors, requirements change, and management decisions. Say, if management decides to skip investing in disaster recovery hardware, "blaming a single developer" for an electricity outage in the datacenter would just not make sense.

Tell them this is only an amateurish name for the Root Cause field used by professionals (when issue tracker does not have dedicated field, one can use comments for that).

Search the web for something like software bug root cause analysis, there are plenty of resources to justify this reasoning 1, 2, 3, 4, ....


...a root cause for a defect is not always a single developer (which is the main point of this field)...

That's exactly why "root cause" is professional while "person to blame" is amateurish. Personal accountability is great, but there are cases when it simply lays "outside" of the dev team.

Tell your boss when there is a single developer to blame, root cause field will definitely cover that ("coding mistake made by Bob in commit 1234, missed by Jim in review 567"). The point of using the term root cause is to cover cases like that, along with cases that go out of the scope of the dev team.

For example, if the bug has been caused by faulty hardware (with the person to blame being someone outside of the team who purchased and tested it), the root cause field allows for covering that, while "single developer to blame" would simply break the issue tracking flow.

The same applies to other bugs caused by someone outside of the dev team - tester errors, requirements change, and management decisions. Say, if management decides to skip investing in disaster recovery hardware, "blaming a single developer" for an electricity outage in the datacenter would just not make sense.

Tell them this is only an amateurish name for the Root Cause field used by professionals (when issue tracker does not have dedicated field, one can use comments for that).

Search the web for something like software bug root cause analysis, there are plenty of resources to justify this reasoning 1, 2, 3, 4, ....


...a root cause for a defect is not always a single developer (which is the main point of this field)...

That's exactly why "root cause" is professional while "person to blame" is amateurish. Personal accountability is great, but there are cases when it simply lays "outside" of the dev team.

Tell your boss when there is a single developer to blame, root cause field will definitely cover that ("coding mistake made by Bob in commit 1234, missed by Jim in review 567"). The point of using the term root cause is to cover cases like that, along with cases that go out of the scope of the dev team.

For example, if the bug has been caused by faulty hardware (with the person to blame being someone outside of the team who purchased and tested it), the root cause field allows for covering that, while "single developer to blame" would simply break the issue tracking flow.

The same applies to other bugs caused by someone outside of the dev team - tester errors, requirements change, and management decisions. Say, if management decides to skip investing in disaster recovery hardware, "blaming a single developer" for an electricity outage in the datacenter would just not make sense.

6 minor wordsmithing
source | link

Tell them this is only an amateurish name for the Root Cause field used by professionals (when issue tracker does not have dedicated field, one can use comments for that).

Search the web for something like software bug root cause analysis, there are plenty of resources to justify this reasoning 1, 2, 3, 4, ....


...a root cause for a defect is not always a single developer (which is the main point of this field)...

That's exactly why "root cause" is professional while "person to blame" is amateurish. Personal accountability is great, but there are cases when it simply lays "outside" of the dev team.

Tell your boss when there is a single developer to blame, root cause field will be suredefinitely cover that ("coding mistake made by Bob in commit 1234, missed by Jim in review 567"). The point of using the term root cause is to cover cases like that, along with cases that go out of the scope of the dev team.

For example, if the bug has been caused by faulty hardware (with the person to blame being someone outside of the team who purchased and tested it), the root cause field allows for covering that, while "single developer to blame" would simply break the issue tracking flow.

The same applies to other bugs caused by someone outside of the dev team - tester errors, requirements change, and management decisions. Say, if management decides to skip investing in disaster recovery hardware, "blaming a single developer" for an electricity outage in the datacenter would just not make sense.

Tell them this is only an amateurish name for the Root Cause field used by professionals (when issue tracker does not have dedicated field, one can use comments for that).

Search the web for something like software bug root cause analysis, there are plenty of resources to justify this reasoning 1, 2, 3, 4, ....


...a root cause for a defect is not always a single developer (which is the main point of this field)...

That's exactly why "root cause" is professional while "person to blame" is amateurish. Personal accountability is great, but there are cases when it simply lays "outside" of the dev team.

Tell your boss when there is a single developer to blame, root cause field will be sure cover that ("coding mistake made by Bob in commit 1234, missed by Jim in review 567"). The point of using the term root cause is to cover cases like that, along with cases that go out of the scope of the dev team.

For example, if the bug has been caused by faulty hardware (with the person to blame being someone outside of the team who purchased and tested it), the root cause field allows for covering that, while "single developer to blame" would simply break the issue tracking flow.

The same applies to other bugs caused by someone outside of the dev team - tester errors, requirements change, and management decisions. Say, if management decides to skip investing in disaster recovery hardware, "blaming a single developer" for an electricity outage in the datacenter would just not make sense.

Tell them this is only an amateurish name for the Root Cause field used by professionals (when issue tracker does not have dedicated field, one can use comments for that).

Search the web for something like software bug root cause analysis, there are plenty of resources to justify this reasoning 1, 2, 3, 4, ....


...a root cause for a defect is not always a single developer (which is the main point of this field)...

That's exactly why "root cause" is professional while "person to blame" is amateurish. Personal accountability is great, but there are cases when it simply lays "outside" of the dev team.

Tell your boss when there is a single developer to blame, root cause field will definitely cover that ("coding mistake made by Bob in commit 1234, missed by Jim in review 567"). The point of using the term root cause is to cover cases like that, along with cases that go out of the scope of the dev team.

For example, if the bug has been caused by faulty hardware (with the person to blame being someone outside of the team who purchased and tested it), the root cause field allows for covering that, while "single developer to blame" would simply break the issue tracking flow.

The same applies to other bugs caused by someone outside of the dev team - tester errors, requirements change, and management decisions. Say, if management decides to skip investing in disaster recovery hardware, "blaming a single developer" for an electricity outage in the datacenter would just not make sense.

5 fixed the english by adding all the missing connector words,
source | link

Tell them this is only an amateurish name for the Root Cause field used by professionals (when issue tracker does not have dedicated field, one can use comments for that).

Search the web for something like software bug root cause analysis, there are plenty of resources to justify this reasoning 1, 2, 3, 4, ....


...a root cause for a defect is not always a single developer (which is the main point of this field)...

That's exactly why "root cause" is professional while "person to blame" is amateurish. Personal accountability is great, but there are cases when it simply lays "outside" of the dev team.

Tell your boss when there is a single developer to blame, root cause field will be sure cover that ("coding mistake made by Bob in commit 1234, missed by Jim in review 567"). The point of using the term root cause is to cover cases like that, along with cases that go out of the scope of the dev team.

For example, if the bug has been caused by faulty hardware (with the person to blame being someone outside of the team who purchased and tested it), the root cause field allows to coverfor covering that, while "single developer to blame" would simply break the issue tracking flow.

SameThe same applies to other bugs caused by someone outside of the dev team - tester errors, requirements changeschange, and management decisions. Say, if management decides to skip investing intoin disaster recovery hardware, "blaming a single developer" for an electricity outage in the datacenter would just not make no sense.

Tell them this is only an amateurish name for Root Cause field used by professionals (when issue tracker does not have dedicated field, one can use comments for that).

Search the web for something like software bug root cause analysis, there are plenty resources to justify this reasoning 1, 2, 3, 4, ....


...a root cause for a defect is not always a single developer (which is the main point of this field)...

That's exactly why "root cause" is professional while "person to blame" is amateurish. Personal accountability is great, but there are cases when it simply lays "outside" of dev team.

Tell your boss when there is a single developer to blame, root cause field will sure cover that ("coding mistake made by Bob in commit 1234, missed by Jim in review 567"). The point of using term root cause is to cover cases like that, along with cases that go out of scope of dev team.

For example, if the bug has been caused by faulty hardware (with person to blame being someone outside of the team who purchased and tested it), root cause field allows to cover that, while "single developer to blame" would simply break the issue tracking flow.

Same applies to other bugs caused by someone outside of dev team - tester errors, requirements changes, management decisions. Say, if management decides to skip investing into disaster recovery hardware, "blaming single developer" for electricity outage in datacenter would just make no sense.

Tell them this is only an amateurish name for the Root Cause field used by professionals (when issue tracker does not have dedicated field, one can use comments for that).

Search the web for something like software bug root cause analysis, there are plenty of resources to justify this reasoning 1, 2, 3, 4, ....


...a root cause for a defect is not always a single developer (which is the main point of this field)...

That's exactly why "root cause" is professional while "person to blame" is amateurish. Personal accountability is great, but there are cases when it simply lays "outside" of the dev team.

Tell your boss when there is a single developer to blame, root cause field will be sure cover that ("coding mistake made by Bob in commit 1234, missed by Jim in review 567"). The point of using the term root cause is to cover cases like that, along with cases that go out of the scope of the dev team.

For example, if the bug has been caused by faulty hardware (with the person to blame being someone outside of the team who purchased and tested it), the root cause field allows for covering that, while "single developer to blame" would simply break the issue tracking flow.

The same applies to other bugs caused by someone outside of the dev team - tester errors, requirements change, and management decisions. Say, if management decides to skip investing in disaster recovery hardware, "blaming a single developer" for an electricity outage in the datacenter would just not make sense.

4 formatting kaizen
source | link
    Post Made Community Wiki by hasanyasin
3 minor typo fixed
source | link
2 a root cause for a defect is not always a single developer; added 2 characters in body; added 5 characters in body; edited body
source | link
1
source | link