Hi Ilmari, thanks a lot for your contributions.
In the next few days I'll prepare a document with Sophie and Hossein combining also your comments so that we can start moving forward with a concrete plan and a job description.
I see that you are joining Heiko in proposing to employ a web developer.I suppose that your proposal isn't seen by anyone as being problematic so if the team with the ED create a job description we could get also that approved fairly quickly.
Ciao Paolo On 12/02/2022 22:30, Ilmari Lauhakangas wrote:
On 10.2.2022 23.46, Jan Holesovsky wrote: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?I'm not Michael, but thanks for the helpful points.* How to frame the hiring process - where developers should have a say in it, without being accused of CoI?I would frame the role description to begin with as focusing on underloved areas and thus ecosystem company reps would be very welcome to participate in the interviews etc. As long as they refrain from poaching in the middle of the process ;)* How to make it quick, so that the potential hires are still available once TDF decides for this or that candidate?Maybe time the interviews for a season of the year that we know is not rush hour for all of us.* How to get the developers up-to-speed or mentor them once they are hired?I suppose if the current mentoring capability is not sufficient for specific core hacking deep dives, contracting mentoring from domain experts in the commercial ecosystem would be an option.* Also how to task them, how to day-to-day manage them, and how to make sure they are progressing at a reasonable pace?I will go into the content of the imagined tasks at the end. Regarding smooth progress, one of my self-assumed responsibilities is to protect experts from noise and more trivial or repetitive things, so I think fostering this sort of a supportive environment would help.* What to do if they get stuck, and there is nobody in the community who can help them?Park the stuck task and work on something else.* How to detect they are not performing, and just consume the donors' money?The current way the directors monitor staff seems enough for this role as well.* How to make sure they don't compete with other open source projects, or the ecosystem companies?Trust the more experienced staff members to know this distinction when it comes to areas of focus.* 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?This kind of activity seems detectable by staff, but the previous answer also applies. If some traditionally underloved area would suddenly get regular bug reports, it would in itself draw a lot of attention. Yet, instead of defining some sanctions, I think it would be best to not stress about edge cases no one can fully control, if the end result is shipping good stuff to everyone anyway.* 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"?I'm not sure if it's needed, but this mechanism could be a string placed in the Whiteboard field of a report.* 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?Yes, they should be. The prioritisation arises organically: 1. there is the huge mass of people I mentor2. not all of the people from point 1 even reach the level where Hossein becomes their primary mentor 3. for the core hacking level, the hypothetical staff devs could share the mentoring responsibility, optimally on the areas they themselves are working on* 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.]By regular brainwashing sessions conducted by me (I am well-known for my free advertising of the ecosystem companies before and after my hiring at TDF).* 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.?A possible answer to this is the content of the tasks.What came to my mind about possible tasks when I thought of this in-house dev role are things like- drafting and reviewing tenders (faster and improved experience for ecosystem companies) - code reviews (both to support ecosystem companies and to decrease the workload of their employees on reviewing random patches - sometimes this is done on their free time after all) - GSoC mentoring (less pressure for ecosystem companies as this can get tedious) - "orphaned regressions", from committers who left the project or ecosystem devs who won't get paid for fixing an ancient mistake (this would be a big stress relief for devs in the ecosystem companies who have a heightened sense of responsibility to fix stuff on their free time)- any underloved thing! - fixing build breakages - keeping the toolchain well-oiled- improving developer experience in myriad ways, including making existing code easier to reason aboutAll in all, I just see this as a no-brainer and a huge boon for the ecosystem companies. It would remove a lot of distraction from the workdays of company employees and give the sense that they are not the only Ghostbusters in town that get called to solve the newest crazy phenomenon.Regarding the topic of volunteers vs. paid devs, for sure the directing of volunteers has become easier with the new structured approach to mentoring, but we have to consider the aspect of velocity. It is awkward, if some parts of our ambitious application suite are dragged along in a sort of half-dead state, while others flourish. If not much core hacking is going on somewhere, it becomes much more difficult to direct volunteers to it. A hired dev can reinvigorate an area of the suite and create new easy hacks for it.The web dev idea is off-topic in this thread, but such a person should definitely get hired for many reasons. It is true that a web dev would also improve the core developer experience by enhancing our tooling.Ilmari
-- Paolo Vecchi - Deputy Member of the Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: https://www.documentfoundation.org/imprint
OpenPGP_signature
Description: OpenPGP digital signature
