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