CAcert Code Development list.

[Eva Stöwe <eva.stoewe AT cacert.org>]

Dear Ted,


On 21.02.2017 21:36, Bernhard Fröhlich wrote:
> Am 17.02.2017 um 10:30 schrieb Karl-Heinz Gödderz:
>> [...]
>>> Now, as already mentioned, Dirk has a lot of other jobs, not the least
>>> being a member of the board, so I really would prefer someone else to
>>> take over the job. But if none of you is available, I'd prefer him as
>>> team lead over having no team lead at all.
>>>
>> thank you for your proposal, and as you wrote, it would be better to
>> have a TL than  none.
>> But what are about CoIs Dirk could have as TL and Board member?
>
> Thinking a while about Conflict of Interests between Software
> (Assessment) TL and board, I could not find a practical one, beyond
> the obvious "aggregation of powers".
>
> There may be other potential CoIs, since even I do currently not know
> of all of Dirk's jobs within CAcert, let alone outside. I know that he
> did lend a helping hand to the support team, but I don't know if he'll
> remain active in this area.

Currently he is the only really active person in support team - if he
would stop that now, it would be a real issue with a ruling that I gave
(and should have resolved around the time when I regrettably saw the
need to resign arbitration, so this was not done).

There is a running ABC for Karl-Heinz to add him to support team and a
filed ABC for Ales. But both are not finished, until there is another
active support member, I really would advise against a move from Dirk
out of active support work.

>
> Maybe Dirk can give an overview on the jobs he wants to keep even if
> appointed Software TL?
>
>>
>>> Unless I hear about another candidate, or about facts that speak
>>> against Dirk I'd like to propose board to appoint him as software team
>>> lead.
>>>
>> What about you? Could you take the post of TL instead?
>
> No, sorry. I'm not looking for additional jobs within CAcert and I
> will not accept any.
>
>> And who else is in the software team at the moment, who could take that
>> post?
>
> Since an Arbitrated Background Check is a requirement, at least for
> the Assessment part of the TL job, the choices are very limited.
> Having a look at https://wiki.cacert.org/Software/DevelopmentTeam and
> https://wiki.cacert.org/Software/Assessment/Team leaves not many
> candidates who have not explicitly refused the job or did resign from
> it recently... Maybe Markus Warg? Haven't heard of him for quite some
> time...
>
> I have even less contact to the non-Assessment part of the software
> team, so I cannot tell if there would be any aspirants. A missing ABC
> makes it a bit more complicated, but I guess if there would be a
> serious candidate an ABC could be handled...

Sorry, but there is a ruling [1] from Magu that currently forbids ANY
ABCs until he decides on a new process ... and then he stopped to be an
arbitrator.


The current ABCs are only exceptionally allowed under my ruling of the
case where Dirk became active in support area [2].

Please note: I personally am completely convinced that Magus ruling was
as wrong and incorrect as a ruling can be - he even gave it WHILE he was
active as NRE-TL at exactly the same time, which is excluded by Philpps
ruling [3]. But it is a ruling and by this binding.

Sure, it should be appealed. And I (as respondent of that case) believe
that I have a lot of arguments to do so, properly. But there are already
a multitude of other appeals which are not handled, so it does not make
sense to add another one.

But as the ruling of Magu was actually reducing our security instead of
increasing it, I at least saw some options to allow at least those ABCs
that we currently see. - I also opened a way to do according ABCs in
other areas if the number of active members drop too low. But that is
not related for TL-jobs.

[1] https://wiki.cacert.org/Arbitrations/a20140124.1
[2] https://wiki.cacert.org/Arbitrations/a20141024.1
[3] https://wiki.cacert.org/Arbitrations/a20150420.1

Kind regards,
Eva


>
> Kind regards
> Ted
>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature