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 mentor
2. 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 about
All 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
- so I'm looking forward to
- thank you!