| 1 |
NP-Hardass wrote: |
| 2 |
> >> or do they typically restrict review to a certain class of users? |
| 3 |
> > |
| 4 |
> >Hm, why would that end up happening? I'm not saying it can't, just |
| 5 |
> >that I don't understand why it would. What do you have in mind? |
| 6 |
> |
| 7 |
> Well, it was just proposed earlier in the thread that it could be |
| 8 |
> used for non-devs (primarily/only), hence two classes of users, |
| 9 |
> those subjected to review and those not. |
| 10 |
|
| 11 |
Ah I understand. Personally I think review is just as important for |
| 12 |
devs as for non-devs. The big win with a review tool/flow is that it |
| 13 |
becomes *at all possible* for non-devs to contribute efficiently to |
| 14 |
the project, and if the review tool is good then giving review is |
| 15 |
also efficient. |
| 16 |
|
| 17 |
Some will always be more equal than others, but.. |
| 18 |
|
| 19 |
|
| 20 |
> An alternative is a situation where all users, developer and non |
| 21 |
> developer alike require review |
| 22 |
|
| 23 |
I feel that this is the only way to achieve the best quality. |
| 24 |
|
| 25 |
|
| 26 |
> with the review requirements different between the two |
| 27 |
|
| 28 |
I don't feel that this is as useful for quality. Devs produce crap too. |
| 29 |
|
| 30 |
It's important that the review flow is well-understood and efficient. |
| 31 |
|
| 32 |
It's important that everyone working is *motivated* to participate in |
| 33 |
review. I've had plenty of experience with smart people who simply do |
| 34 |
not want to participate in a review flow and that's all it takes for |
| 35 |
the review flow to fail. |
| 36 |
|
| 37 |
|
| 38 |
//Peter |
Archives