Enable TDF to contribute more code to LibreOffice with in-house developers to address our donors specific needs

Hi all,

Thanks Simon for bringing some ideas to the table, and for all the others that endured the discussion to provide feedback.

For Accessibility, my preference would be to tender for a specialist organisation to either triage accessibility bugs or implement capabilities for a fixed period followed by a performance review and re-tendering (possibly for a longer period). By doing that we would avoid having to also develop in-house engineering management and product accessibility expertise. This is beyond the current tendering practice in that we would ask the successful applicant to also direct and design their work.

I'd just question if a semi-finite number of tenders will solve forever the specific needs of, just for the sake of the argument, a11y. What decided that, for example, UX will have to be a recurring problem that granted the direct employment of someone (thanks Heiko for your efforts!) but a11y or RTL is not?

Honestly, I still feel there are parts of the project that would use much more love and are definitely matter of inclusiveness, but for the various reasons we already know very well and were even touched in the discussion, are laying there suffering.

And yes, sure, employing internal developer is just one of the tools we can deploy to assure a greater sustainability of the community and the Foundation, and not the only one.

Cheers,

Hi Emiliano!

Thanks for the feedback. I appreciate your thoughtfulness here, and I agree with you wholeheartedly.

On Thu, Feb 10, 2022 at 9:47 PM Emiliano Vavassori <syntaxerrormmm@libreoffice.org> wrote:

I’d just question if a semi-finite number of tenders will solve forever
the specific needs of, just for the sake of the argument, a11y. What
decided that, for example, UX will have to be a recurring problem that
granted the direct employment of someone (thanks Heiko for your
efforts!) but a11y or RTL is not?

I agree it’s non-obvious - but there was thinking behind it! For user experience, the expert (hi Heiko!) had to be an influencer and servant-leader rather than acting primarily as a developer as user experience design has a significant dimension of setting an overall direction and then persuading all the developers to follow it. In many ways this is more of a senior mentorship role, and the recipients of the guidance are not beginners but rather super-experienced developers who consent to being guided. The role is ideally met by having an expert on staff. (FYI I wrote about this at the time)

For accessibility, there are definitely elements that have a similar profile and a good argument could be made for having an accessibility architect on staff playing a similar role to Heiko in mentoring the “college of developers” to consider accessibility in their work. On the whole, the LibreOffice developer college is fairly tuned-in to accessibility though.

The challenges are often attached to systemic issues and need extended time of LibreOffice experts to unpick the root cause before implementing the fix - even specifying them to tender takes research and pre-work as I expect you know. We’ve tendered these sorts of issues, and we could consider employing someone to deal with them full time, yes. However, there are also specialist elements - having accessibility devices for testing, for example. My sense is we would be better off paying an existing expert team (there are a few companies who specialise, not necessarily “the usual suspects”) to take on the whole backlog for us for maybe 18 months, doing both engineering management and implementation and joining the ESC while they do. After that I’d return to the topic and reconsider the best approach in the light of that experience.

It’s possible that RTL might surrender to the same approach, but that’s not an area I have focussed on in my career so I’d want to hear from product managers who have dealt with it. I’d be open to whatever was the best solution. We need to discuss each of these topics on their own merits.

Honestly, I still feel there are parts of the project that would use
much more love and are definitely matter of inclusiveness, but for the
various reasons we already know very well and were even touched in the
discussion, are laying there suffering.

I definitely agree. I think it needs discussing and breaking down topic-by-topic though, as each area will have an optimal approach (and may have a different optimal approach once the backlog is dealt with). As in much of life, easy answers are unlikely to be correct answers!

And yes, sure, employing internal developer is just one of the tools we
can deploy to assure a greater sustainability of the community and the
Foundation, and not the only one.

I’m also concerned by the “centralised service” challenges I mentioned in my earlier e-mail. I have thought about the subject a great deal, over several years, and I do think TDF could embark on a direction to serve the individual citizen in this area independently of the business solutions. But this is a topic where there are significant challenges from the vested interests of almost all the directors, so addressing it is going to be tough. I certainly don’t want to “just hire a few people and see what happens” on this one!

Cheers!

Simon

Hi Michael,

[reordered for the sake of a linear argument]

Michael Weghorn wrote:

and I remember that the importance of users was emphasized at some in-person
event I attended (probably Akademy) as well.

And I would agree. A user-facing project (opensource or not) that
doesn't care about users in the aggregate is probably doing something
wrong.

Just to mention it, the KDE Code of Conduct contains this:

> Our community is made up of several groups of individuals and
> organizations which can roughly be divided into two groups:
>
> * Contributors, or those who add value to the project through
> improving KDE software and its services
> * Users, or those who add value to the project through their
> support as consumers of KDE software

I'm not sure KDE would have a fundamentally different view here, but
happy to have that conversation & perhaps hear new, fresh perspectives.

For a code of conduct, it makes of course sense to include users
(conduct is about interactions), so if contributors interact with
users, ground rules of kind behaviour should apply.

To clarify what I mean (and why I think KDE's take is not so
different), the KDE manifesto [1] has this:

* End-User Focus to ensure our work is useful to all people

I'm perfectly in-line with that mission statement, as a guiding
principle. But I would not turn down a contribution because it doesn't
meet that standard yet (and instead try mentoring and other ways to
improve it over time). I would, though, dismiss user requests that
don't meet community norms, and not bother mentoring everyone until
they understand.

For perspective: it is not a scalable task to care for 200 million
users individually. It is though a priority for me (and I hope
achievable), to care for all our contributors, individually. Thus,
mentoring existing, and attracting new contributors will always have a
higher priority to me, than fixing end-user bugs (with project
resources).

Of course, there's nuance. The areas you and others have mentioned,
that would need special attention, are worth tackling.

Of course, one could try to make a distinction between users that
contribute something back and those who do not, but I don't know
whether that would be particularly helpful, or even easy. (E.g. is
a user that only uses the software for themselves not part of the
community, but one who recommends it to others is, because they
"spread the word"? - And maybe one of those starts getting active in
some "official" area in the LibreOffice project, or migrates their
company from a proprietary office suite to an LTS version from an
ecosystem company,...)

Perhaps it's a different meaning I ascribe to the term 'user' in this
discussion. The moment someone starts contributing to the project,
this person becomes a contributor to me (in contrast to a mere
anonymous user). Let's gloss over grey areas, as in, when does a
contribution start to 'count' - I think it doesn't matter for this
discussion (and surely there's different yardsticks anyway for that,
between TDF sub-projects considering someone to have merit, over to
how the MC evaluates contribution).

So yes, from your list, it would be a distinction to me.

[1] https://manifesto.kde.org/

Best,

-- Thorsten

Hi Kendy,

thanks for sharing your thoughts/concerns!

I have expressed elsewhere in this thread that I am a proponent of
hiring more development mentors rather than generic developers; so it
is hard for me to get excited about this proposal.

Also I forgot to answer Heiko elsewhere that his idea of graphics
designer / website developer in one person sounds reasonably positive
to me.

I believe that not being excited about the idea is totally valid. Let me explicitly mention that I'm also open to other suggestions and how they would help to move forward with the issues that were brought up.

As mentioned in my reply to Michael [1] however, I'm currently not so convinced whether "plain" development mentors would have the same chance of providing success when it comes to progress in *specific* areas (which does not at all mean I'm against having more mentors in general).

Having said that, maybe we can get a bit more constructive even in this
  discussion about hypothetical possibility of hiring generic
developers; so what about this:

Michael, please - would you be willing to further your (and Sophie's)
idea in form of a document that can be discussed as a whole,
particularly how the details together fit the TDF mission?

While I wouldn't say I came up with the general idea, I'm happy to contribute my thoughts in case the decision in today's BoD meeting is that it's worth having such a document for further discussion.
I don't think I'll be able to do that just by myself (and there are certainly people who know better "how TDF works"), but I'm definitely willing to be part of a group that creates such a document.

I'll reply with some first thoughts to your questions below for further discussion without claiming those are "the ultimate answers". In any case, I'm happy to learn and hear other opinions.

I myself would be interested in the following questions; do you think
you can cover them some way, please?

* How to frame the hiring process - where developers should have a say
   in it, without being accused of CoI?

I'm not familiar with the TDF hiring process. Is it so that the BoD is involved here and ultimately takes the decision?
If so, I don't see any lack of competent developers in the new BoD to cover that perspective. :slight_smile:

In my previous email I wrote that I personally wouldn't assume a CoI in case the tasks of TDF developers were set accordingly, and it definitely sounds reasonably to me for all BoD members to have a say.

I'm not too familiar with the CoI policy, but as I understand it, the remaining BoD decides whether or not a CoI exists for a specific member.
So would that point be addressed in case all BoD members agreed that all BoD members can have a say in the vote?
(Whether or not all BoD members agree here is obviously a question I cannot answer.)

* How to make it quick, so that the potential hires are still available
   once TDF decides for this or that candidate?

I'm not familiar with the TDF hiring process, but I would assume the answer here should be unspecific to the specific role of the person being hired and would arise just the same in case of hiring more development mentors instead.

* How to get the developers up-to-speed or mentor them once they are
   hired?

That probably depends on whether the hired developers are completely new to the project or have participated previously.
In general, I'd go with the established approach that is used for non-TDF contributors as well (have them learn by doing).

* Also how to task them, how to day-to-day manage them, [...]

(splitting this here, second part of the sentence below)

That's up to discussion, my initial idea outlined in my previous email [2] would be to involve ESC and/or BoD when it comes to larger topics to be worked on.

I personally wouldn't see a need to control every single small item that they work on but give them some "freedom" to work on what they identify along the way as they work on larger topics.
But if there's a concern that would be problematic, more micro-management from BoD (or some representative that has been assigned by the BoD to take care) would of course be possible as well (like assigning specific Bugzilla tickets to work on or first discuss the thoughts they come up while doing their other work).

[...] and how to make
   sure they are progressing at a reasonable pace?

* What to do if they get stuck, and there is nobody in the community
   who can help them?

I think those are questions that every developer is facing. My personal perception is that developers are working together well and there has so far basically always been help from others when somebody asks for specific help at a certain point (via developer mailing list or IRC).

* How to detect they are not performing, and just consume the donors'
   money?z

As above for the hiring process: I think the BoD has experienced developers who should be able to judge that. (And I think otherwise e.g. the team could help assess that, e.g. in the hypothetical case a future BoD didn't have any developers; there are people in the TDF team whom I'd trust to have sufficient insight into development to do so).

* How to make sure they don't compete with other open source projects,
   or the ecosystem companies?

* How to make sure they are not misused by (any, not only ecosystem)
   companies to fix bugs for them or for their customers? [Particularly
   companies disguised by @gmail or so addresses in bugzilla.]

I think that's a matter of setting the right tasks (or, on a different level, having the right processes to decide on tasks), as outlined above and in my previous email. [2]

* On the other hand - how to make it possible to cherry-pick fixes or
   features into the release branches of ecosystem companies without
   the risk of being accused of misusing the previous point?

To be honest, I don't see any risk here. However, in case there are concerns, the answer would probably be the same as above to ensure they are working on the "right" tasks in the first place. (In a free and open source project, it's just fine to reuse the work of others, and the case of cherry-picking other contributors' commits to vendor branches you describe already happens in LO all the time and I don't see a relevant difference for the case a certain developer is working for TDF.)

* Should there be a mechanism for the ecosystem companies to flag a bug
   "this is what I'm working on for a customer - please don't touch"?

One simple way that comes to my mind would be to just assign the bug in Bugzilla.
But in case there's actually a specific need to establish a different mechanism for specific cases, why not?

* With my pet idea of development mentors rather than generic
   developers in mind - should they be mentoring too, and if yes, how
   to prioritize vs. the actual development?

That's up to discussion. One potential idea mentioned in my reply to Michael [1] that would IMHO fit well with the idea of advancing in specific areas would be to give them responsibility over a certain area to improve. In case other people are interested in working on that area, mentoring them should IMHO have a higher priority at that point in time since it's good to get others involved.

* How to avoid growing a group-think in the internal developers
   group that there is no need for the ecosystem companies, or even
   for the community as a whole? [As explained elsewhere; as much as
   it sounds strange - TDF is a subset of the community, not the other
   way around.]

I completely agree with the "TDF is a subset of the community" part.
The described scenario would indeed be very unfortunate, but I don't see a risk here, in particular for the case where TDF employs a small amount of developer with the main focus to take care of neglected areas. (It might be more relevant in case employing a large amount of developers were discussed.)

In general, having the right atmosphere of working together in the community is probably the most important point here. At least in my personal experience so far, I did not at all have the impression of destructive competition among developers, but rather people working together nicely and helping each other, and I don't see why adding a few TDF developers to the mix would change that.

* How to avoid TDF internal developers to feel (or worse, to be)
   "more equal" than the rest of the community - particularly when
   there is no 1/3 rule for them, direct access to release engineering
   and admins (their colleagues), etc.?

The answer here is probably mostly the same as the previous one.
I currently don't see any reason to not have the same standard processes of contribution for them that all other developers also use.

Considering your reply to Andreas [3], I guess I'm missing the personal "OpenOffice.org/Oracle experience" to be able to better imagine such a situation, but I see no reason for assuming the same could happen with LibreOffice again.

I am sure this list is not exhaustive, and suppose others will
contribute, but hope it is a start.

Thanks again! My attempt to provide potential answers is certainly also not exhaustive and I'm happy to hear other opinions on that.

Best regards,
Michael

[1] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00209.html
[2] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00177.html
[3] https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00190.html

Hi Thorsten,

Michael Weghorn wrote:

and I remember that the importance of users was emphasized at some in-person
event I attended (probably Akademy) as well.

And I would agree. A user-facing project (opensource or not) that
doesn't care about users in the aggregate is probably doing something
wrong.

I completely agree here and that was also one motivation of writing my previous email.

This is not directed to you at all, but I sometimes have the impression of hearing some notion of "Why should we care about the users that don't contribute anyway?" in some discussions, which I personally don't like.

At least for myself, improving LibreOffice for our users (including those that don't contribute at all) is a crucial aspect in my personal motivation to contribute to the project.

Just to mention it, the KDE Code of Conduct contains this:

Our community is made up of several groups of individuals and
organizations which can roughly be divided into two groups:

* Contributors, or those who add value to the project through
   improving KDE software and its services
* Users, or those who add value to the project through their
   support as consumers of KDE software

I'm not sure KDE would have a fundamentally different view here, but
happy to have that conversation & perhaps hear new, fresh perspectives.

The quote was mainly in response to the question of whether or not (non-contributing) users should be regarded as part of the community.

In case there was interest in getting some fresh perspectives, I'm wondering maybe talking about that in some Advisory Board meeting might make sense, given that e.g. GNOME and KDE are members there.

To clarify what I mean (and why I think KDE's take is not so
different), the KDE manifesto [1] has this:

* End-User Focus to ensure our work is useful to all people

I'm perfectly in-line with that mission statement, as a guiding
principle. But I would not turn down a contribution because it doesn't
meet that standard yet (and instead try mentoring and other ways to
improve it over time). I would, though, dismiss user requests that
don't meet community norms, and not bother mentoring everyone until
they understand.

Thanks for the explanation, that sounds completely reasonable to me (at least as long as the contribution isn't known to badly break things for a certain group that worked previously).

For perspective: it is not a scalable task to care for 200 million
users individually. It is though a priority for me (and I hope
achievable), to care for all our contributors, individually. Thus,
mentoring existing, and attracting new contributors will always have a
higher priority to me, than fixing end-user bugs (with project
resources).

Of course, there's nuance. The areas you and others have mentioned,
that would need special attention, are worth tackling.

I totally agree that's generally a reasonable approach and looking at it on a case-by-case basis as needed makes sense.

Best regards,
Michael

Hi Simon,

thanks for all your considerations regarding accessibility.

The challenges are often attached to systemic issues and need extended time of LibreOffice experts to unpick the root cause before implementing the fix - even specifying them to tender takes research and pre-work as I expect you know. We've tendered these sorts of issues, and we could consider employing someone to deal with them full time, yes. However, there are also specialist elements - having accessibility devices for testing, for example. My sense is we would be better off paying an existing expert team (there are a few companies who specialise, not necessarily "the usual suspects") to take on the whole backlog for us for maybe 18 months, doing both engineering management and implementation and joining the ESC while they do. After that I'd return to the topic and reconsider the best approach in the light of that experience.

I can see pros and cons for both approaches (internal developer, tender).

In case of tendering, I think some cooperation of a11y experts and LO experts (like a company specializing on a11y + "one of the usual suspects") might even be more ideal than just an a11y-specialized company by itself, since from what I've seen so far, I suspect that some of the issues are somewhere deep down in the Writer/Calc/... stack that might take people without any previous experience with LibreOffice development quite a while to get into.

In any case, I think it would be important to also make sure that there will be a possibility to get a11y issues fixed in the future as well.
In case of a TDF developer, that should be relatively straight-forward because the developer can "just work on it".
In case of tendering, I would see a need for some kind of arrangement that will allow to hand out follow-up tasks without having to go via the usual tendering process, which would otherwise allow an issue that is identified today to be considered only in a proposal for next year's tendering budget, so there would be quite a delay.
(I don't know whether that's possible, but maybe, some longer-running contract to be able to hand out additional smaller work items flexibly as needed might be a solution, once the initial work has been finished.)

Best regards,
Michael

Completely agree with what you said.

Hi Kendy,

Michael, please - would you be willing to further your (and Sophie's)
idea in form of a document that can be discussed as a whole,
particularly how the details together fit the TDF mission?

I think Michael provided very relevant feedback in many areas (thank you!) but it would be unfair to impose on him to also start writing documents which should be prepared with the help of our team.

As I started the proposal I'm very happy to work with Sophie and Hossein to complement the proposal with the useful feedback we received in this thread.

Ciao

Paolo

Hi Italo,

Italo Vignoli píše v Čt 10. 02. 2022 v 18:28 +0100:

I would have applauded a reaction to the message that has opened
this
thread which was integrating the proposal with some additional
thoughts
and suggestions, to specify which could be the areas where a
developer
hired by TDF could work for the common benefit of the project.

I see, thank you for the explanation!

I have expressed elsewhere in this thread that I am a proponent of
hiring more development mentors rather than generic developers; so it
is hard for me to get excited about this proposal.

Also I forgot to answer Heiko elsewhere that his idea of graphics
designer / website developer in one person sounds reasonably positive
to me.

Having said that, maybe we can get a bit more constructive even in this
  discussion about hypothetical possibility of hiring generic
developers; so what about this:

Michael, please - would you be willing to further your (and Sophie's)
idea in form of a document that can be discussed as a whole,
particularly how the details together fit the TDF mission?

I myself would be interested in the following questions; do you think
you can cover them some way, please?

I'm not Michael, but thanks for the helpful points.

* How to frame the hiring process - where developers should have a say
   in it, without being accused of CoI?

I would frame the role description to begin with as focusing on underloved areas and thus ecosystem company reps would be very welcome to participate in the interviews etc. As long as they refrain from poaching in the middle of the process :wink:

* How to make it quick, so that the potential hires are still available
   once TDF decides for this or that candidate?

Maybe time the interviews for a season of the year that we know is not rush hour for all of us.

* How to get the developers up-to-speed or mentor them once they are
   hired?

I suppose if the current mentoring capability is not sufficient for specific core hacking deep dives, contracting mentoring from domain experts in the commercial ecosystem would be an option.

* Also how to task them, how to day-to-day manage them, and how to make
   sure they are progressing at a reasonable pace?

I will go into the content of the imagined tasks at the end. Regarding smooth progress, one of my self-assumed responsibilities is to protect experts from noise and more trivial or repetitive things, so I think fostering this sort of a supportive environment would help.

* What to do if they get stuck, and there is nobody in the community
   who can help them?

Park the stuck task and work on something else.

* How to detect they are not performing, and just consume the donors'
   money?

The current way the directors monitor staff seems enough for this role as well.

* How to make sure they don't compete with other open source projects,
   or the ecosystem companies?

Trust the more experienced staff members to know this distinction when it comes to areas of focus.

* How to make sure they are not misused by (any, not only ecosystem)
   companies to fix bugs for them or for their customers? [Particularly
   companies disguised by @gmail or so addresses in bugzilla.]
> * On the other hand - how to make it possible to cherry-pick fixes or
   features into the release branches of ecosystem companies without
   the risk of being accused of misusing the previous point?

This kind of activity seems detectable by staff, but the previous answer also applies. If some traditionally underloved area would suddenly get regular bug reports, it would in itself draw a lot of attention. Yet, instead of defining some sanctions, I think it would be best to not stress about edge cases no one can fully control, if the end result is shipping good stuff to everyone anyway.

* Should there be a mechanism for the ecosystem companies to flag a bug
   "this is what I'm working on for a customer - please don't touch"?

I'm not sure if it's needed, but this mechanism could be a string placed in the Whiteboard field of a report.

* With my pet idea of development mentors rather than generic
   developers in mind - should they be mentoring too, and if yes, how
   to prioritize vs. the actual development?

Yes, they should be. The prioritisation arises organically:
1. there is the huge mass of people I mentor
2. not all of the people from point 1 even reach the level where Hossein becomes their primary mentor
3. for the core hacking level, the hypothetical staff devs could share the mentoring responsibility, optimally on the areas they themselves are working on

* How to avoid growing a group-think in the internal developers
   group that there is no need for the ecosystem companies, or even
   for the community as a whole? [As explained elsewhere; as much as
   it sounds strange - TDF is a subset of the community, not the other
   way around.]

By regular brainwashing sessions conducted by me (I am well-known for my free advertising of the ecosystem companies before and after my hiring at TDF).

* How to avoid TDF internal developers to feel (or worse, to be)
   "more equal" than the rest of the community - particularly when
   there is no 1/3 rule for them, direct access to release engineering
   and admins (their colleagues), etc.?

A possible answer to this is the content of the tasks.

What came to my mind about possible tasks when I thought of this in-house dev role are things like

- drafting and reviewing tenders (faster and improved experience for ecosystem companies)
- code reviews (both to support ecosystem companies and to decrease the workload of their employees on reviewing random patches - sometimes this is done on their free time after all)
- GSoC mentoring (less pressure for ecosystem companies as this can get tedious)
- "orphaned regressions", from committers who left the project or ecosystem devs who won't get paid for fixing an ancient mistake (this would be a big stress relief for devs in the ecosystem companies who have a heightened sense of responsibility to fix stuff on their free time)
- any underloved thing!
- fixing build breakages
- keeping the toolchain well-oiled
- improving developer experience in myriad ways, including making existing code easier to reason about

All in all, I just see this as a no-brainer and a huge boon for the ecosystem companies. It would remove a lot of distraction from the workdays of company employees and give the sense that they are not the only Ghostbusters in town that get called to solve the newest crazy phenomenon.

Regarding the topic of volunteers vs. paid devs, for sure the directing of volunteers has become easier with the new structured approach to mentoring, but we have to consider the aspect of velocity. It is awkward, if some parts of our ambitious application suite are dragged along in a sort of half-dead state, while others flourish. If not much core hacking is going on somewhere, it becomes much more difficult to direct volunteers to it. A hired dev can reinvigorate an area of the suite and create new easy hacks for it.

The web dev idea is off-topic in this thread, but such a person should definitely get hired for many reasons. It is true that a web dev would also improve the core developer experience by enhancing our tooling.

Ilmari

1 Like

Hi Ilmari,

thanks a lot for your contributions.

In the next few days I'll prepare a document with Sophie and Hossein combining also your comments so that we can start moving forward with a concrete plan and a job description.

I see that you are joining Heiko in proposing to employ a web developer.

I suppose that your proposal isn't seen by anyone as being problematic so if the team with the ED create a job description we could get also that approved fairly quickly.

Ciao

Paolo

Hi Paolo,

Paolo Vecchi píše v Pá 11. 02. 2022 v 16:11 +0100:

As I started the proposal I'm very happy to work with Sophie and
Hossein
to complement the proposal with the useful feedback we received in
this
thread.

Perfect, I am looking forward to an ODT that we can then collectively
redline as the Board, to form a proposal based on consensus!

As to working with Sophie & Hossein - are you about to politely ask
them to work on that as volunteers (as I've asked Michael W. - Michael,
once again thank you for your input & answers!), or are you about to
ask your fellow Board members & Florian to dedicate some of their work
time (ie. donation money) to work on the proposal?

Thank you!

All the best,
Kendy

Hi Kendy,

I'm not Paolo,

but maybe it would be great, if you could stop to pick on someone.

It seemed your only intention on this topic is to control (with your
non-TDF-hat on) everything.

That is not a cooperative behavior.

Regards,
Andreas

Hi Ilmari,

Thank you for your answers, lots of great stuff! Just two notes:

Ilmari Lauhakangas píše v So 12. 02. 2022 v 23:30 +0200:

> * How to make sure they don't compete with other open source
> projects,
> or the ecosystem companies?

Trust the more experienced staff members to know this distinction
when
it comes to areas of focus.

I fear it shouldn't be about trust only :slight_smile: - so I'm looking forward to
the Paolo's promised document, I hope it will cover it some way too.

> * How to avoid growing a group-think in the internal developers
> group that there is no need for the ecosystem companies, or even
> for the community as a whole? [As explained elsewhere; as much
> as
> it sounds strange - TDF is a subset of the community, not the
> other
> way around.]

By regular brainwashing sessions conducted by me (I am well-known for
my
free advertising of the ecosystem companies before and after my
hiring
at TDF).

Love this one! :smiley: - thank you!

All the best,
Kendy

Hi Andreas,

Andreas Mantke píše v Po 14. 02. 2022 v 15:29 +0100:

but maybe it would be great, if you could stop to pick on someone.

It seemed your only intention on this topic is to control (with your
non-TDF-hat on) everything.

That is not a cooperative behavior.

I've told it in the public part of the Board meeting on Friday, and
will repeat it again: I am very sad that this whole discussion started
framed as (let me paraphrase) "TDF will hire 2 developers, it is all
done deal, there are no problems" [in concrete words "Funds are
available for at least 2 developers allowing us to start employing them
straight away; Next steps: create and publish the job offers for
developers and on-board them ASAP"].

This is extremely unhelpful, as it totally dismisses views of others.
There was no full agreement of this in the Board, no plan, no
prioritization against other budget items and no consideration if this
is the best way how to improve the situation - so please don't be
surprised it lead to a challenging discussion.

I am extremely grateful to Sophie, Michael W., Ilmari, Olivier H., and
others (I'm sure I forgot some, sorry about that) for their patience &
helpful input, and I do hope we will move to a more constructive,
concrete debate.

In my world [regardless of the hat], a constructive debate is much
easier over a document collecting:

* the problem statement & the need
* the pros & cons of various solutions
* the proposal & conclusion

That with change tracking (redlining) turned on & possibility to
comment - so that it is possible to finalize it to a form that is
acceptable for all involved: in other words, to form a consensus.

So - I am really looking forward to such a document! Actually I'd be
happy to start it myself, if that helped the situation; and would ask
people to volunteer to work with me on that - but not sure it is a good
idea just now.

All the best,
Kendy

Hi Kendy, all,

Hi Andreas,

Andreas Mantke píše v Po 14. 02. 2022 v 15:29 +0100:

but maybe it would be great, if you could stop to pick on someone.

It seemed your only intention on this topic is to control (with your
non-TDF-hat on) everything.

That is not a cooperative behavior.

I've told it in the public part of the Board meeting on Friday, and
will repeat it again: I am very sad that this whole discussion started
framed as (let me paraphrase) "TDF will hire 2 developers, it is all
done deal, there are no problems" [in concrete words "Funds are
available for at least 2 developers allowing us to start employing them
straight away; Next steps: create and publish the job offers for
developers and on-board them ASAP"].

but that gave TDF the option to work on tasks which are important for
the LibO user and for the market strength of the LibreOffice community
edition.

This is extremely unhelpful, as it totally dismisses views of others.
There was no full agreement of this in the Board, no plan, no
prioritization against other budget items and no consideration if this
is the best way how to improve the situation - so please don't be
surprised it lead to a challenging discussion.

I'm sorry but it seemed the challenging discussion is done only by one
person.

And don't be surprised that there is not always full consensus in a
decision process. At some point you have to decide with the majority of
votes to avoid endless discussions.

I am extremely grateful to Sophie, Michael W., Ilmari, Olivier H., and
others (I'm sure I forgot some, sorry about that) for their patience &
helpful input, and I do hope we will move to a more constructive,
concrete debate.

Maybe you made excessive demands on their patience and self-perception.

In my world [regardless of the hat], a constructive debate is much
easier over a document collecting:

I think it is (nearly?) impossible to take part in a debate, if you have
a CoI (because you sit on two sites of a table).

Regards,
Andreas

Hi Kendy,

Hi Paolo,

Paolo Vecchi píše v Pá 11. 02. 2022 v 16:11 +0100:

As I started the proposal I'm very happy to work with Sophie and
Hossein
to complement the proposal with the useful feedback we received in
this
thread.

Perfect, I am looking forward to an ODT that we can then collectively
redline as the Board, to form a proposal based on consensus!

Thanks, I'm looking forward to having the board agreeing that it's the best strategic move for TDF to start employing internal developers.

I'm sure that if all board members think about the best for TDF we will reach an unanimous consensus on it very quickly.

As to working with Sophie & Hossein - are you about to politely ask
them to work on that as volunteers (as I've asked Michael W. - Michael,
once again thank you for your input & answers!),

As to working with Sophie and Hossein I have publicly asked members of TDF's team to work together on an opportunity that affects them, as we are talking about new colleagues, and on which they can share their thoughts and experience as they are working in many areas and are able to identify the best ways to get the new developers to be most effective within the team and for the good of our wider community.

True that I could have added the word "please", I was probably too excited to start working with members of the team and totally forgot, but I'm sure both Sophie and Hossein didn't get offended by it.

  or are you about to
ask your fellow Board members & Florian to dedicate some of their work
time (ie. donation money) to work on the proposal?

Our team must invest its time for the best of TDF, LibreOffice and the wider community and that's what our donors want.

Keep also in mind most volunteers are also donors as time for most of us has a value.

I'm generally selling my time at X amount per hour/day so I'm donating that value to TDF with the only scope of doing my best for TDF, LibreOffice and the community as I passionately believe on the project and the good that it's doing all over the world without expecting any economical return. Naturally there is a limit on the amount of time I can donate as while it makes me happy to be doing my best for TDF and the community, like anyone else, I have to dedicate my time also in doing things that pay the bills.

Others may be able to invest as much time as it is necessary as anyway some outcomes may be also quite beneficial for their own companies, that may create a bit of an imbalance in the decision making process.

Thank you!

Thank you for understanding how much many are donating in time and money to TDF and that we need to move forward to show them their donations really matter to us.

All the best,
Kendy

Ciao

Paolo

Hi Kendy,

On 14/02/2022 16:42, Jan Holesovsky wrote:

Hi Andreas,

Andreas Mantke píše v Po 14. 02. 2022 v 15:29 +0100:

but maybe it would be great, if you could stop to pick on someone.

It seemed your only intention on this topic is to control (with your
non-TDF-hat on) everything.

That is not a cooperative behavior.

I've told it in the public part of the Board meeting on Friday, and
will repeat it again: I am very sad that this whole discussion started
framed as (let me paraphrase) "TDF will hire 2 developers, it is all
done deal, there are no problems" [in concrete words "Funds are
available for at least 2 developers allowing us to start employing them
straight away; Next steps: create and publish the job offers for
developers and on-board them ASAP"].

The proposal is a proposal not a contract.

This is extremely unhelpful, as it totally dismisses views of others. 
There was no full agreement of this in the Board, no plan, no
prioritization against other budget items and no consideration if this
is the best way how to improve the situation - so please don't be
surprised it lead to a challenging discussion.

I do understand your point of view as I found it “very regrettable” that my views and proposals that were clearly stated in my candidacy statement got dismissed by others.

I did have a conversation with the board trying to explain that this is a strategic decision that shouldn’t be seen as a ranked project but my point of view was totally ignored by those that didn’t care much about respecting others’ views.

Then others tried to dismiss my proposal trying to frame it as us vs others political battle:

’ + very regrettable (Simon)

  • to frame this as partisan - one side vs. another
  • particularly when one side is “the industry”’

That last line is also very regrettable as “the industry” (2 suppliers very well represented in the board) seem to be more equal than others and if we don’t listen to “the industry” very bad things will happen.

I am extremely grateful to Sophie, Michael W., Ilmari, Olivier H., and
others (I'm sure I forgot some, sorry about that) for their patience &
helpful input, and I do hope we will move to a more constructive,
concrete debate.

It has been a very constructive debate which seems to show that most have understood that my proposal has many ramifications that will help TDF in moving forward in a positive way.

The good thing is that even the members of the ecosystem seem to have seen the proposal as beneficial for all the parties involved.

We should have more of these debates in public so that the team and the community can tell us if we are going in the right direction.

In my world [regardless of the hat], a constructive debate is much
easier over a document collecting:

* the problem statement & the need
* the pros & cons of various solutions
* the proposal & conclusion

Something like this?:

  • As shown by Italo’s slides at FOSDEM again and by others, TDF is not contributing as much as it could
  • Up to now no strategic decisions have been taken to make TDF a more regular and active code contributor
  • Members of the ecosystem and others also suggested that we should spend more money in development
  • Bugs, a11y issues and features can be harder to taken care of by volunteers and are not always addressed by the ecosystem
  • We need to build up internal skills and development capabilities to speed up innovation
  • Lack of suppliers diversification, mostly 2 at present, is a suboptimal situation for TDF, LibreOffice and its community
  • Internal developers can grow to cover areas like mentoring and QA while also helping with new contributors support
  • TDF needs to expand its internal capacity to deal with publishing in app stores directly and manage variable levels of complexity due to ever changing rules
  • Some proposed projects could be developed internally instead of outsourcing them, which helps to grow in-house skills and capacity to address our donors needs
  • Potential App Stores revenues may allow for more developers and to invest in developing other projects
  • Our development mentor together with the team should propose to the BoD projects for internal development
  • While internal projects may cover different areas tenders and ESC proposals will be also evaluated to avoid effort duplication
  • This is not “just” a new project, it’s an essential and strategical move for TDF to grow further in its second decade which widens the horizon for new visions and opportunities to do more and even better things for LibreOffice and our community
  • Funds are available for at least 2 developers allowing us to start employing them straight away
  • Next steps: create and publish the job offers for developers and on-board them ASAP

This has allowed to get a feel for the proposal, which seems very positive, and now we’ll be working on the details but at least it showed that the community thinks we are moving in the right direction.

Then should the new developers invest 30% of their time in QA, 50% in bug fixing and 20% in reviewing tenders and deliverables?
That’s something we should see with the team as they have a very good feel of what is going on.

That with change tracking (redlining) turned on & possibility to
comment - so that it is possible to finalize it to a form that is
acceptable for all involved: in other words, to form a consensus.

We’ve done that or better tried to do that. When the initial direction is not yet set it has shown to be a total waste of time.

A good example was that third party company, we wasted months as some wanted to justify it at all cost while others where asking to look at the evidence showing that it was not a good idea at all. Lots of red lining and “vandalised documents” as some comments were pointing out what was actually seriously wrong.
Same thing happened for many other discussions.

Let’s do things in the open, let’s get the community to comment on the proposal and then we can work together to go in the right direction.

So - I am really looking forward to such a document!  Actually I'd be
happy to start it myself, if that helped the situation; and would ask
people to volunteer to work with me on that - but not sure it is a good
idea just now.

Be patient.

As a volunteer not earning any money with LibreOffice development or support I need a bit more time than others to liaise with the team members and start writing documents.

All the best,
Kendy

Ciao

Paolo

I think at least some of the push back is less against the concept that
TDF should hire developers and more that it's a clearer path to start
with some specific problems and then what options could solve them and
hiring can be an option on that decision tree. It's a rare dev that has
skills in multiple appstores, mentoring, qa, a11y, CTL, CJK and
bugfixing in the various quite diverse components.

Hi Caolán,

thanks for your feedback.

I think at least some of the push back is less against the concept that
TDF should hire developers and more that it's a clearer path to start
with some specific problems and then what options could solve them and
hiring can be an option on that decision tree. It's a rare dev that has
skills in multiple appstores, mentoring, qa, a11y, CTL, CJK and
bugfixing in the various quite diverse components.

Keep in mind that the point of the proposal was to get feedback from the community and the team which seems to confirm that it is desirable to have in-house developers to take care of certain areas.

Now that we know we want in-house developers, the team and the interviews will help in determining which areas we can start covering.

We have already identified that we have the in-house skills to manage the app stores but internal developers, together with external expertise if necessary, can help in adapting LibreOffice packages to deal with the eventual changes and issues that may arise when app store rules change.

If interviews show that there are interested parties that are also specialised, or have a good grasp, of a11y, RTL and CJK then that will help in determine what they will cover otherwise we will need to see if they can and are interested in growing their skills in those areas.

Developers could also dedicate part of their time in QA and mentoring while helping in validating tenders and their deliverables so I'm sure that nobody will get bored and everyone over time will have the opportunity to show in which areas they perform best.

At this stage there are many areas that need to be covered and everyone in the team has demonstrated to be capable in adapting and perform many different tasks. The same adaptability will be, at least at the beginning, appreciated from the new members of the team.

Over time funds coming from app stores and donations will allow us to further grow our team and will allow members of the team to focus more in specific areas if they wish.

I'm fully aware that this is not the way established development/consulting companies work but TDF isn't one and it needs to build up its internal skills organically for the reasons explained in this thread.

Ciao

Paolo

It is recognized that in-house developers (...) may be a (partial) solution some of the issues we face.
So I really look forward to the proposal you are working on that will address all the ideas and questions we saw in the discussion so far.

Cheers,
Cor