Hi Michael, Michael Weghorn píše v So 28. 05. 2022 v 21:21 +0000:
> I think having Paolo's original proposal and this one in a form > that's > easy to compare is very helpful. Thank you! > 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. Indeed - I'm trying to find the middle ground... > 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. Please don't get me wrong - I believe the appstores is an important discussion, just don't want to block the hiring on that; as I think it is orthogonal to that. > 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. Perfect. > 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? Ah - it is the extension of the rationale how the development itself fits the TDF mission, ie. doesn't make that much sense without the previous paragraph that starts "Why is it important to major on mentoring". So how about: "Development per se is not part of TDF mission, but it is expected that while a mentor 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." Does it make more sense this way? > 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). Great. > 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? Indeed, I should clarify this; I think changing "Overlaps or prioritisations that find ..." to "Technical decisions that find..." could do? > 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? The hope is that there will be many applicants, and that we'll have the possibility to choose two. But if there is only one good candidate, I think we should not start another round of interviews until we evaluate the experience - because the process is expensive & time consuming. > 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. Very good point :-) > 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.) What about "... will not develop alternative implementations of Open Source projects actively maintained by LibreOffice volunteer or corporate contributors."? LOOL could be an example, but there is eg. the Kohei's mdds (that is essential for the Calc core), or Moggi's maintenance of cppunit - hosted on freedesktop, but using LibreOffice bugzilla for bugreports. All the best, Kendy -- 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
