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+unsubscr...@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
