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