| 1 |
On 10/07/2016 08:15 AM, Kristian Fiskerstrand wrote: |
| 2 |
> On 10/07/2016 05:07 PM, Nick Vinson wrote: |
| 3 |
>> |
| 4 |
>> |
| 5 |
>> On 10/07/2016 08:00 AM, Kristian Fiskerstrand wrote: |
| 6 |
>>> On 10/07/2016 04:54 PM, Nick Vinson wrote: |
| 7 |
>>>> If the developer is really a problem, |
| 8 |
>>>> then ComRel will be given repeated chances to deal with the developer |
| 9 |
>>>> and eventually (well hopefully not eventually) the "due process" will be |
| 10 |
>>>> done correctly and the developer will be removed. |
| 11 |
>>> |
| 12 |
>>> Not necessarily, bringing back might on its own open up for especially |
| 13 |
>>> PR issues, but also potentially legal ones. So its not as simple as |
| 14 |
>> s |
| 15 |
>> Maybe, but I'd happily accept any bad PR that resulted in me choosing |
| 16 |
>> not to punish a dev because it was unclear that the dev deserved it. |
| 17 |
>> |
| 18 |
> |
| 19 |
> At that point it becomes a bit murky. if bringing in a dev again it'd |
| 20 |
> require monitoring by comrel at the very least to avoid issues (what if |
| 21 |
> the dev has a grudge and commits a "fix" that is malicious in nature etc?). |
| 22 |
> |
| 23 |
> One alternative is to consider it a pure utility-function / cost-benefit |
| 24 |
> consideration at that point where U(f(),g(),h()) where f() is determined |
| 25 |
> by the value of the commits/support of the developer while being a dev, |
| 26 |
> and g() the cost of maintenance burden, and h() is event risk to overall |
| 27 |
> community or negativity due to pushback from other existing and |
| 28 |
> potential devs wanting the one in question gone, so it can reduce |
| 29 |
> long-term recruitment due to the negative PR etc. |
| 30 |
> |
| 31 |
|
| 32 |
Certainly, you could do that. However, I would ask for objective |
| 33 |
measures for U(), f(), g(), and h() which wouldn't be an easy task. |
| 34 |
|
| 35 |
> |
Archives