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

Board Discuss
#41

Hi Italo,

thanks for your reply.

Of course, in case the main intention were for TDF to provide more business-like services (like an LTS version or creating an impression of "donate a certain amount of money and your pet bug will be fixed"), I see very well how that might interfere significantly with the business model of ecosystem companies.

Totally agree. But I don't see the issue, as ESC and BoD members could easily stop any project before it starts, when there is a potential risk of conflict. AFAIK, major development activities are scrutinized by both bodies, as they are ranked in order of importance, suggested, approved and transformed to tenders, or not considered for tendering.

I totally agree, extending that process to cover significant tasks that internal developers would work on may be a solution.

Development activities which are not considered for tendering, or just ignored, could probably be developed by TDF without creating disruptions (or even discussions).

To double-check nobody is "secretly" working on that as well or is planning to do so, discussing/mentioning larger items first certainly won't hurt.
(But that doesn't only apply for work done by TDF developers; e.g. the weekly ESC call already has a "What’s cooking" section where that would fit well.)

I am rather sure that in 7 million lines of code (plus the open bugs) there are enough challenges for everyone.

Definitely!

Of course, given my complete lack of understanding of development, is too easy to find a technical angle to disprove what I just wrote, [...]

Best regards,
Michael

#42

Hi *,

with the lively discussion ensuing here, it is perhaps worth sharing
my position ahead of the board call tomorrow:

Paolo Vecchi wrote:

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

I think it is worth considering, whether TDF should employ dedicated
developers. I'm not in general against it.

It is putting the cart in front of the horse though, to start with:

* we want TDF to contribute more code to LibreOffice

and then follow with

* therefore we must employ two developers

I believe it is more productive to start thinking about what we want
to achieve, in order to fulfill our mission. It is therefore
encouraging to read some good thoughts about that (RTL/CTL, a11y, and
other under-developed areas with little ecosystem contributions).

The board can then ponder what is the best way to achieve those goals,
relative to other demands. It is possible, but by no means certain,
that actually hiring specialised staff is indeed the most economic way
forward (e.g. for an area like a11y).

It should be noted though, also to manage expectations, that mastering
even a small area in LibreOffice takes many years to learn. So hiring
for a role has long-term implications then on which kind of tasks,
features or bugfixes can be done in-house.

Cheers,

-- Thorsten

#43

Hi Thorsten,

Sole users (i.e. without contributing anything to the community) are
to my mind never part of a FLOSS project community.

Just to mention it, the KDE Code of Conduct [1] 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

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

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,...)

Best regards,
Michael

[1] https://kde.org/code-of-conduct/

#44

I am not questioning the legitimacy and composition of the board, I am questioning the behaviour of its members.

#45

Hi Thorsten!

Thanks for your positive contribution which I agree with completely (although I do have a comment, see below).

On Thu, Feb 10, 2022 at 5:09 PM Thorsten Behrens <thb@documentfoundation.org> wrote:

Hi *,

with the lively discussion ensuing here, it is perhaps worth sharing
my position ahead of the board call tomorrow:

Paolo Vecchi wrote:

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

I think it is worth considering, whether TDF should employ dedicated
developers. I’m not in general against it.

It is putting the cart in front of the horse though, to start with:

  • we want TDF to contribute more code to LibreOffice

and then follow with

  • therefore we must employ two developers

I believe it is more productive to start thinking about what we want
to achieve, in order to fulfill our mission. It is therefore
encouraging to read some good thoughts about that (RTL/CTL, a11y, and
other under-developed areas with little ecosystem contributions).

The board can then ponder what is the best way to achieve those goals,
relative to other demands. It is possible, but by no means certain,
that actually hiring specialised staff is indeed the most economic way
forward (e.g. for an area like a11y).

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.

It should be noted though, also to manage expectations, that mastering
even a small area in LibreOffice takes many years to learn. So hiring
for a role has long-term implications then on which kind of tasks,
features or bugfixes can be done in-house.

Cheers,

– Thorsten

–

#46

I disagree. This is the result of BoD members pointing fingers to each other without even trying to start a discussion and reach consensus.

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.

Sorry, but I haven't seen anything like this so far.

#47

Hi Sophie, hi all,

And I feel the same. Hiring developers is not the only way forward,
it's one of them. We, as members, knows the ecosystem companies have
needs and I (for myself) understand perfectly the market pressure. But
here, as a member of TDF, we contribute with the ecosystem companies,
not for them.

I agree. you simply wrote what I was thinking to add. thanks.

Their is even no written proposal at the moment, but only a discussion
on the pros and cons and what it could bring to the project. But it
seems impossible to discuss because the ecosystem companies won't
allow it.
I'm sorry, I already wrote in a previous thread that TDF has failed to
have a balanced position during the pandemic, caring of the charitable
part of its duty, I hope we will not continue in that way because,
again as a member, this is not how I feel represented.

...and I fully agree again.

Cheers,
Marina

#48

Hi Michael, all,

  It seems reasonable to explore what people should be hired to do -
before hiring them =) That has the benefit of working out what skills
are needed in the job advert and/or interview process for example. The
'discussion' here - I would not see as blocked, but problematic see
later.

I don't think the discussion is even at this point. Reading the messages I can only see some board members just questioning every single commas used by the others, fighting in public without even realising that all this drama is only bringing away community members interested to share more ideas and proposals for solving this deadlock we are experiencing.

  As for no-one listening to users - I spend my life listening to
customers & partners & users - and trying to do what they want. Anyone
jealous of some big pool of unconstrained money / development power in
corporate contributors is mistaken. Nevertheless I still get
impassioned complaints of why Collabora did X and not Y from
intelligent, articulate, engaged community members.

...and again, it's not always "Collabora vs others" discussion. There's a discussion, not even a concrete proposal on how TDF could contribute more code, there are other opinions shared and an attempt to really act like a community that tries to shape its own projects. Can we stop to reduce every possible discussion to the "ecosystem vs all the others"?

We are all part of the same project, many of us were part of it from day 0, some officially, others unofficially, but we were all there.
Can we stop to act like kids and try to really cooperate like adults?

  As for finding new board members on the list to express a view you
feel represents you: these long threads packed with trolling and
misrepresentation on board-discuss are not a great way to interact I
suspect. Why would a new board member want to engage in them while
they find their feet ? Lets not be quick to preemptively despair of
sensible decision making.

This way to act is not only affecting the board members. It has a negative impact on the full community and on all the potential new contributors that are just scared away by all those dramas.

  These days the we have created rules to exclude people from such
decision making - which has the potential to significantly exacerbate
conflict and division I feel.

...talking about trolling, I was indeed missing yet another comment against the CoI policy.

Cheers,
Marina

#49

Hi Michael (W.),

I absolutely agree with what you wrote.
My deepest thank you for being so open-minded!

Of course, in case the main intention were for TDF to provide more business-like services (like an LTS version or creating an impression of "donate a certain amount of money and your pet bug will be fixed"), I see very well how that might interfere significantly with the business model of ecosystem companies.

Totally agree. But I don't see the issue, as ESC and BoD members could easily stop any project before it starts, when there is a potential risk of conflict. AFAIK, major development activities are scrutinized by both bodies, as they are ranked in order of importance, suggested, approved and transformed to tenders, or not considered for tendering.

I totally agree, extending that process to cover significant tasks
that internal developers would work on may be a solution.

Development activities which are not considered for tendering, or just ignored, could probably be developed by TDF without creating disruptions (or even discussions).

To double-check nobody is "secretly" working on that as well or is
planning to do so, discussing/mentioning larger items first certainly
won't hurt.
(But that doesn't only apply for work done by TDF developers; e.g. the
weekly ESC call already has a "What’s cooking" section where that
would fit well.)

I am rather sure that in 7 million lines of code (plus the open bugs) there are enough challenges for everyone.

Definitely!

Of course, given my complete lack of understanding of development, is too easy to find a technical angle to disprove what I just wrote, [...]

Thanks again,
Marina

#50

Hi Thorsten, all,

It is putting the cart in front of the horse though, to start with:

* we want TDF to contribute more code to LibreOffice

and then follow with

* therefore we must employ two developers

Whether or not that's an adequate summary of Paolo's proposal is not up to me to judge, but...

I believe it is more productive to start thinking about what we want
to achieve, in order to fulfill our mission. It is therefore
encouraging to read some good thoughts about that (RTL/CTL, a11y, and
other under-developed areas with little ecosystem contributions).

The board can then ponder what is the best way to achieve those goals,
relative to other demands. It is possible, but by no means certain,
that actually hiring specialised staff is indeed the most economic way
forward (e.g. for an area like a11y).

... I completely agree that having a clear goal and considering the pros and cons of different approaches to get there before taking a decision definitely makes sense.

Best regards,
Michael

#51

Hi all!

Their is even no written proposal at the moment, but only a discussion
on the pros and cons and what it could bring to the project. But it
seems impossible to discuss because the ecosystem companies won’t allow it.

And yet it seems here we are discussing it! It’s fun to do things that aren’t allowed :slight_smile:

The OP did indeed not make a written proposal, but there still a Board Motion to hire two developers despite this. Personally (and I don’t work for any “ecosystem company” or TDF or belong to a local group) I don’t feel either the OP’s proposal or any other response commenting on it here represents me.

I volunteered here because I think LibreOffice is massively important to the free/open source software movement, as well as to the freedom of citizens globally, including especially non-English-speaking and differently-able people. I want to see TDF spend its money in the service of that global movement to the maximum extent it has allowed itself to in its bylaws. I especially believe TDF needs to act to allow individuals to avoid the need to use centralised services for making, reading and sharing documents of all kinds.

Right now TDF is not doing so, despite being given millions of euros by end-users. My concern is thus not with the desire to spend donated money on donor problems - we should do more of it, and better, and not let any corporate interest stop us. My concern is with accepting as agreed the proposal that TDF should hire developers and afterwards address what they would do, how and under whose supervision. I can see significant risks from doing so and I do not want in any way to endorse that premature proposal.

So sure, let’s have a pros and cons discussion. I have already chipped in positively elsewhere and look forward to being able to amplify other positive ideas, But first let’s take the political and premature motion off the table so that no-one feels their contribution is either supporting or opposing it. It has led to an essential discussion becoming yet another divisive fight and that’s got to stop.

Cheers!

Simon

#52

Hi Michael, all,

There is a huge amount of need around LibreOffice development. It is easy to find a hundred different "top priority" issues each dear to the heart of a user, each user convinced that if only we had eg. 'Reveal Codes' in writer everyone would use LibreOffice.

True, and I think there is consensus that not everybody's personal "top priority" issue can be handled, no matter what steps are taken in the end.

As for no-one listening to users - I spend my life listening to customers & partners & users - and trying to do what they want. Anyone jealous of some big pool of unconstrained money / development power in corporate contributors is mistaken. Nevertheless I still get impassioned complaints of why Collabora did X and not Y from intelligent, articulate, engaged community members.

To mention it explicitly: Thanks for all that you and Collabora are doing for LibreOffice, that's much appreciated and I think nobody here is expecting Collabora to solve all problems by itself.

TDF in contrast while it has many constraints on what it can do - has few time constraints on its spending, which frees it to do more strategic long-term work. Thus it can invest more efficiently with some multiplying factor - via the educational / mentoring role into specific areas. I for one would support some targeted a11y / CTL mentoring - those seem like good areas that Sophie outlines - and ones where we can perhaps shine & grow the contributor community.

However - there is a cliff-face of need here. It seems totally sensible to suggest that hiring internal developers without any plan of working out what they should work on seems premature. Part of why mentors are attractive is that their agenda is partly lead by what volunteers want to do. That can be steered of course by creating new easy-hacks / tasks / projects in directions they want to go - and/or learning on the job themselves by hacking on things.

I completely agree that TDF has different constraints than other contributors and that could allow, among others, for doing more strategic work, rather than only focusing on single bugs that are important to specific users.

I'm not so sure, though, whether mentoring alone will be enough to ensure that otherwise neglected areas will sufficiently be taken care of.
For that to work, there at least need to be capable people willing to be mentored and to work on those topics, and having a certain amount of time to do so. I'm skeptical whether having more mentors alone will necessarily also provide for that.

I am wondering whether dropping a strict distinction between the two roles (developer, mentor) might help here. My expectation would be that a TDF developer currently "responsible" for a certain area would also be a great mentor in case people willing to work on that show up.
And once other contributors are willing to take care of specific areas, I believe it makes sense to allow them to work on that and have TDF staff focus on something else.

I think some flexibility depending on how things develop would nicely be able to deal with both scenarios: the one where other contributors interested in a specific topic show up, as well as the one where they don't.

For myself, I would want to see some sensible mechanism that includes the views of those who contribute via donations as to what is important. Then again if we dedicate donations solely in-line with what donors want - I suspect certain key functions: admin, marketing might not get the attention they deserve: so again, there is no obvious solution here beyond the board getting wide input and deciding (as they do now).

While I understand that details need to be sorted out on how to prioritize potential development topics to be worked on, I believe it should be doable to find a way.

But I don't see the issue, as ESC and BoD members could easily stop
any project before it starts, when there is a potential risk of conflict.

These days the we have created rules to exclude people from such decision making - which has the potential to significantly exacerbate conflict and division I feel.

But you're right, in theory the BoD is sovereign.

In my previous email, I wrote:
"Assuming members in the involved LibreOffice/TDF bodies found a way to work together constructively, my current impression is that this approach could be for the benefit of all."

I admit that this will probably be very hard if members of the involved LibreOffice/TDF bodies don't find a way to work together constructively, but rather "fight against each other". But I think that's a problem on a completely different level, and I don't see how TDF can properly serve it's purpose then anyway, regardless of the specific question around TDF-internal developers being discussed here...

Best regards,
Michael

#53

Hi,

Hi Andreas,

Andreas Mantke píše v St 09. 02. 2022 v 19:58 +0100:

once I read this sentences the first time, I thought I was in a
different film in 2010. But maybe I didn't understand the situation
in OOo project at that time.

I may be wrong, it is a long time ago, but from what I remember, the
problem was not the domination per se [though please don't understand
me as supporting domination ;-)], but the unwillingness to communicate
& seek consensus how to improve the situation for contributors.

it seemed there are different worlds for developer and other community
members.

I and others had the impression that the project domination by one
company at that time wasn't healthy and that the engagement of this
dominant player would end very soon (because of their business
management model).

This was the reason why we get involved in the LibreOffice project from
day one.

We, the majority of the German speaking community members, left the OOo
project and had to fight against accusatory mails from employees etc.

But we withstand this violating situation and invested a lot of our
spare time and resources to make the German language project vital.

Thus I think it is important for community members, which remember the
situation of 2010, to avoid a situation, where only or nearly only one
company dominates the project and especially one area of the project.

The incorporation of a foundation was meant to avoid such situation. But
currently I think, the idea behind this action was not shared by all TDF
members and maybe we had to have set stricter rules to avoid cluster
risk in the TDF bodies.

And one thing which I take with me from this discussion is the evidence
that it is (nearly?) impossible to wear two hats at the same time.

Regards,
Andreas

#54

+1 from me

Ciao

Paolo

Note to self: propose to institute a position for an honorary member of the board.

#55

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?

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

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

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

* Also how to task them, how to day-to-day manage them, 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?

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

* 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.]

* 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?

* 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"?

* 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?

* 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.]

* 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.?

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

Thank you in advance!

All the best,
Kendy

#56

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,

#57

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

–

#58

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

#59

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

#60

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

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.