ESC tendering policy changes ...
Dr. David Alan Gilbert
dave at treblig.org
Fri Apr 21 23:13:19 UTC 2023
* Michael Meeks (michael.meeks at collabora.com) wrote:
> Hi there,
>
> > * ESC tender project proposal process (Thorsten)
> > + proposal would be: (Thorsten)
> > + share the draft in public: see
> > https://nextcloud.documentfoundation.org/s/YprpsFP45z7a7p3
>
.....
> + the unnecessary lengths we go to exclude people: the three
> years is egregiously punitive - particularly in light of
> the forward looking Declaration of Potential Conflict; lets
> remove it. The future matters, for future tendering, not
> the past.
As someone who has very recently left a large relevant company,
the other problem is that in a large company there are people who
are on entirely different projects with no overlap with TDF stuff.
Excluding ~300k people seems a little exessive when a few 10s of them
may be relevant.
Dave
> + the effort we go to to exclude people - when the output of
> this is just good advice for the board to act on is staggering.
>
> + the balance seems very substantially wrong in terms
> of preserving our statutory meritocracy & efficiency
>
> + it is not worth sacrificing these to this extent to
> try to solve every possible concern someone could
> raise: there is already significant ongoing risk of people
> using such spurious concerns to unbalance our governance.
>
> + Effort Estimate & exclusion is silly:
>
> + excluding the few non-conflicted experts in the
> space - who are vital to review the code is totally
> counter-productive.
>
> + if someone is not going to tender, and is not
> affiliated - just assessing the estimate
> should not exclude them from further process -
> such as eg. seeing if it was delivered properly.
>
> + it is very unclear what rational can be used to
> add a whole extra layer of CoI here.
>
> + the pool of skilled people here in any specific
> area is small.
>
> + There are also many deeply wrong ideas embedded in
> this idea of an accurate effort estimate.
>
> wrong premise 1. that effort is easy to estimate - for
> extreme accuracy it takes a significant %age
> of the time to do the job.
>
> + such estimates are best done by 2x
> skilled people, with a range of
> best/likely/worst triple-point
> estimates, breaking down the problem
> etc.
>
> + even so - fixed-priced projects bankrupt
> skilled consultancies in all industries,
> even non-innovative traditional ones eg.
> building projects.
>
> wrong premise 2. that all engineers have the same
> skill/experience level - there is no
> "person day" - this varies 10x depending
> on the person even among experienced engineers
> cf. Fred Brooks, passim ad nauseum
>
> wrong premise 3. that person days can be meaningfully linked
> to cost for a fixed-price project.
>
> + pricing include risk of overruns
>
> + pricing includes load factors & other
> concurrent bids, capacity, probability of
> other bids closing etc. this is a commercial
> nightmare; think Ryan-Air, over-selling the
> plane by a factor of two.
>
> + payment risk as well as reputational risks of
> contracting for TDF are -very- substantial.
>
> the only sensible determination of price is
> by seeing the result of a public, contested
> tendering. To pretend otherwise is silly.
>
> 4. many tendered fixed-price tasks cost the people
> executing on them rather more than they are bid
> for - not even the companies with the experts
> can get this perfectly right.
>
> + worse - this quest for an accurate estimate seems to
> serve no very useful purpose. It is fine to have a
> hyper-accurate number, but if no-one will deliver it in
> that time - you wasted your time.
>
> + I would suggest that we instead have a process that
> ranks tasks, tenders them by priority top-down and then
> decides on reasonableness based on a number of ball-park
> estimates.
>
> + the wisdom of crowds can give us several rough
> ball-parks reasonably easily.
>
> + and otherwise to completely ignore this step, or
> at least explain what extra purpose it tries to solve
>
> + Obvious hostages to fortune:
>
> "Only non-Conflicted Members can vote in the ESC."
>
> + this needs to be profoundly (and redundantly)
> specialized - in the text - to avoid its mis-use,
> and mis-quoting outside the context of this policy.
>
> + please add many more un-necessary words - Carlo
> has made a nice neat text, but the messy political
> reality is of constant word twisting at TDF.
>
> + the sign that we need a 'Note:' here to stop
> people panic-ing - is a good one that this
> will cause problems and mis-understandings
> in future.
>
> + wherever there is a note - make the text
> more verbose, and clearer as to scope at
> the expense of redundancy.
>
> + this will save much acrimony & discussion
> in future - the definition of Conflicted here
> is excessively broad for no obvious reason, it
> should not be widely applied.
>
> With those fixed, it looks fine - plenty of non-controversial & well
> drafted stuff in there. In fact - I'm rather pleased with the tone, approach
> and balance in general - it's refreshing.
>
> Since the ESC has (as yet) not been poisoned, and still works by
> consensus - it seems good to build a social solution on top of that here
> that can work well to avoid the (AFAICS) totally theoretical problem of
> people advising the board to invest in one thing or another.
>
> As I said in the call, there are ideas to have simpler ways to avoid all
> of this legalese: for example having the Trustees vote on things they
> particularly like / want - although - generally (having helped to run the
> ranking in the past) - it is like pulling teeth even getting enough
> individuals of the ESC to spend the hour(s) it takes to read all the
> proposals, give them a fair hearing and provide a sensible ranking for them.
> Possibly this could be a bonus for membership.
>
> Then again the ESC has traditionally focused on on-sexy, technical debt
> type things that we can be sure no-one else will be able to do for fun /
> afford.
>
> Regards,
>
> Michael.
>
> --
> michael.meeks at collabora.com <><, GM Collabora Productivity
> Hangout: mejmeeks at gmail.com, Skype: mmeeks
> (M) +44 7795 666 147 - timezone usually UK / Europe
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
More information about the LibreOffice
mailing list