Date: prev next · Thread: first prev next last
2022 Archives by date, by thread · List index


Hi Kendy, all,

On 26/05/2022 17.08, Jan Holesovsky wrote:
Good idea, Paolo, thank you.  The new version that merges the proposals
is in:

   https://nextcloud.documentfoundation.org/f/960049

as

   TDF-In-House-Developers-Proposal-v2.1.odt

All my changes are change-tracked, so it should make the review
easy.  I've also removed some bits that are controversial, and OTOH not
blocking the hiring.

thanks for this.
I think having Paolo's original proposal and this one in a form that's easy to compare is very helpful.

When getting over this, I've primarily looked at the places for which change-tracking was indicating changes.

Hope this fits the community needs? - comments much appreciated!

Some notes/thoughts:

After reading the discussion on the mailing list, I was surprised that the overall direction still seems very similar to the one in Paolo's unmodified proposal.


Various changes look like they were mostly of a stylistic kind, or to formulate things in a less controversial way, without changing the proposal of what should be done. I haven't spent much time thinking about every single one of those in detail, but they look mostly reasonable to me.


Removal of section "App stores management": As mentioned earlier, I agree that it makes sense to separate the app store topic from the current proposal of hiring developers, and focus on areas that are currently not receiving enough attention otherwise.


Section "The solution: Hire a Targeted Developer": This sounds mostly good to me and if I understand correctly, also mostly fits with what I wrote earlier in the discussion. [1] With the goal of improving areas that are neglected, having those developers take responsibility for specific "oversight/target areas" (by either improving them themselves or by mentoring others) looks like the right approach to me, and it IMHO makes sense to focus on mentoring others in case capable people interested in working on those areas show up. This way, TDF developers can potentially cover more areas over time, as work is shared.

The following passage in that section is a bit unclear to me:

It is also expected that while the Targeted Developer is unable to
actively contribute to public and professional education for whatever
reason (eg. absence of volunteers) that they will be researching and
increasing their experience by contributing to new ways to advance the
free software and standards in their particular Target Areas.

Can you clarify what that means in practice?
Is the idea something like "Targeted developer should spend N % of their time on "education purposes", so if that time isn't spent on mentoring other contributors, let's find other ways to do so? (I think it definitely makes sense to get deeper into the topic and cooperate with other organizations and free software projects. I still think that the main focus should be to achieve practical improvements in LO. Depending on the target area, I can think of more or less way that this would naturally involve contributing to other free software projects etc, but - given limited resource - I personally wouldn't necessarily see contributing to other projects or doing research as a main goal by itself, at least not in the beginning.)


Section "Selecting Target Areas": This sounds reasonable to me (applying a similar process to the tendering one and have ESC suggest, but BoD ultimately decide on target areas).


Section "Project management" has this:

The Targeted Developer will have the same rules, rights and conditions
as any other volunteer or corporate contributor to the code under TDF
umbrella. Overlaps or prioritisations that find no clear conclusion
between the Targeted Developer and the ESC will be decided by  an ESC
vote, as is standardized for any overlaps in the development of the
LibreOffice code, and applicable to all volunteer and corporate
developers. For avoidance of doubt, by no means the Targeted Developer
or TDF leadership by tasking the Targeted Developer can overrule
code-related decisions as decided by the ESC.

I completely agree to the first sentence.

However, the part that ESC has the ultimate decision in case of overlap or prioritisation replaces one in Paolo's proposal where BoD would have the ultimate decision there.

I think it would be in line with the previous section "Selecting Target Areas" if BoD would have the final say when it comes to prioritisation of target areas/tasks for the developer(s) (which I *thought* was what Paolo's proposal meant to say).

In case of different opinions on a more technical level I'd completely agree that ESC should be the committee that would have the final say, just as is the case for any other contributor. (The last sentence seems to fit well with this.)

As I understand it, your reply to Paolo [2] seems to be in line with this, but can you please clarify this?


Section "Bootstrapping":
The initial proposal suggests to employ 2 developers, while the modified one suggests to "start with hiring a single Targeted Developer initially, with the option to expand this to two if multiple suitable candidates present at the interview stage". What's the practical difference of the initial proposal of planning to hire two developers (and then only employing one, if only one suitable candidate shows up) and the new proposal? Does this mostly mean that there will be no further job advertisement once a first developer has been employed, or is there more to it? (Given that the section mentions that this will be re-evaluated after a year, I personally don't have a strong opinion on this either way, but if the budget to employ two targeted developers is there, I'd see no need to limit this to one.)



Section "Concerns expressed by the commercial contributors" has this under 1):

TDF in-house developers will not compete with commercial contributors and will not develop 
alternative implementations of other Open Source projects.

IMHO, this is a bit too generic, since e.g. "developing (something in) LibreOffice" could be seen as developing an alternative to OpenOffice.org, which is an open source project. In case that was primarily directed at something specific (e.g. LTS versions or LOOL): Can that be made more specific? (LTS is already covered by 4), anyway.)



Best regards,
Michael

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

--
To unsubscribe e-mail to: board-discuss+unsubscribe@documentfoundation.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.documentfoundation.org/www/board-discuss/
Privacy Policy: https://www.documentfoundation.org/privacy

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.