TYPO3 Core Development - Mentoring

#1

Mentoring

As we discussed in several team meetings and as comments on slack and on this platform, it would make sense to have some form of mentoring for new core developers in place, so effort of non-core-team-members does not get lost / spent in vain. Therefore I prepared a possible mentoring strategy with requirements and process definitions. I’m eager to hear your feedback.

Description

Wording

  • Contributor: Mentee / person to be mentored
  • Mentor: Member of the core team agreeing to mentor someone

Pre-Requisites for the Core Team Member

  • Interested in mentoring a topic / a person working on the TYPO3 Core
  • Available for architectural discussions
  • Willingness to regularly check on current implementation state with contributor
  • Clear focus area / requirements for Mentees
  • Participation in status meetings (for example Core Team Hangouts), to regularly communicate current state

Process

Start / Kick-Off Phase

The mentoring process can be started via different entry points:

  • Contributor opens a topic on “decisions.typo3.org”
  • Contributor asks in Slack channel
  • Contributor pushes patch in related area

If any of the above happens, the potential mentor for the respective topic should contact the contributor to start the mentoring process.
If the mentor fails to notice the contributor he/she may be triggered by other team members, to ensure no contributors are forgotten or left behind ;).
After getting in touch with the contributor both should have a kick-start talk / meeting to clarify goals, focus and processes.

Implementation phase

While the contributor is actively working on a topic the mentor should

  • Be available for any questions by the contributor / answer at least once a week
  • Have regular status meetings (for example every two weeks) with the contributor
  • Review the corresponding patches and steer the contributor if necessary
  • Report about the current state back to the core team (for example via monthly hang-out)
  • If in doubt the mentor should ask fellow core team members for their opinion, to make sure the contributor produces a widely accepted solution
Finalization
  • If the patches are ready they are reviewed by the mentor again and announced in the core development channel to get more reviews
  • The mentoring process ends when the planned goals are reached
  • The mentor should discuss further steps with the contributor, to keep motivation high and the contributor active

Preparation

If we agree on this process, core team members add themselves to a document with a short description and an area they would mentor. We will then write a news announcing the mentoring including the potential mentors so contributors can also actively contact people - the list of people and areas should also be added to the team page on typo3.org

Organizational

Topic Initiator: Susi Moog
Topic Mentor: Susi Moog

2 Likes
#2

Sounds like a good plan and actually reflects what happened during the dev of the new Session Storage code for v8.

#3

In general a good idea, but I am unsure if the current active core devs can handle the additional workload. But that is up to the devs signing up.

IMHO it would be more important to put the technical discussions back into the open (e.g. here on https://decisions.typo3.org) instead of hiding them in the slack channel. This would allow more people to follow the development process, especially if they are not available during the usual discussion hours and/or cannot attend code sprints.

1 Like
#4

Good plan. If there is a clear topic that one specific mentor can fill he/she is of course a great contact for the mentee. But maybe we’ll also have “universal” mentors without one fixed topic who basically help, mentor and relay to other persons of the core-team with specific questions.

#5

I don’t mean to throw wrenches into any engines here, but I think this is a good time to remind you how much of your time this session storage rewrite ended up costing you personally, how comparatively small that code base was. Don’t get me wrong, it was nice to have you available to such a degree, but even with the amount of availability you offered us, we had problems getting timely reviews for the contributions - this is in no way any complaint towards you as a person, we all have limits and schedules!

I’m just saying: mentoring is nice but it is excessively demanding of the mentor and if not done right, just leaves the mentee without guidance and with even more unanswered questions because now, only one person can answer them as opposed to an entire team of people.

I do not believe this is the right strategy. You’ve already got a serious problem with available manpower and this will probably make it worse.

And my personal recommendation to any core team members reading this: do not sign up for something that you do not have the available time to follow through - don’t underestimate just how much effort a mentoring situation will demand!

#6

@namelesscoder The idea with mentoring is actually that we get people to care for specific topics, so we mitigate our current review problem a bit. Your topics are a pretty good example, it would make sense to have someone from the core team dedicated to these, as then we could ensure that your code gets reviewed in a more timely fashion. Having that core team member defined beforehand would also ensure that you don’t spend a lot of time on a topic that in the end won’t be accepted. In my eyes it’s about a shift of priorities and effort thus becoming more efficient as a team. If you have another idea on how to ensure continuous guidance and reviewing - especially of bigger topics coming from non-team members that need reviews by team members - I’d be happy to hear it :slight_smile:

#7

Slightly OT, sorry about that. But I should answer your question.

Instead of getting more work and more decisions out of existing core team members, maybe consider inviting new ones, instil them with the right priorities, inform them of the overall vision about direction - and leave them free to make decisions without additional gatekeepers. Instead of pooling core developer attention in specific areas, make sure that you don’t get one merge request with ten core developers’ attention and others with zero. And again, I am not attacking or accusing anyone here - I’m just noting that distributing the workload is part of the equation, but doing so requires quite a lot of discipline which I’m currently not experiencing as a contributor. I see this pooling of efforts happening often, usually with no explanation as to why patch XYZ is more important than ABC.

I’m sincerely worried about the mass we have to work with. The core developer circle seems to get smaller while the workload gets bigger and bigger, and that’s not a sustainable situation. Furthermore, there’s no publicly communicated vision about the direction in terms of bigger picture: for example, are we wanting to go further in replacing some of our inventions with Symfony components and limit maintenance burden? What’s the general plan regarding system extensions - which new ones are being considered, which new ones would be desired, which existing ones need attention and how. Which features would be great - which ones would be bad? My experience is that the development vision is clouded, at least when viewed from the outside - and that attention, even if not controlled by interests or popularity, is in short supply.

If everyone knows the expectations and priorities before going into contributions, mentoring probably wouldn’t be necessary, or at least would only be necessary if there is no particular vision for an area of contribution (in which case, the mentoring should become the vision and be published). Anyone, including non-core-team members, can refer to an overall vision as rough explanation why something should be done differently, should be abandoned or should expect lower priority. As it is now, everything is one big pile of seemingly equally prioritised patches with attention striking seemingly at random.

Final points:

  • I believe that publicly and precisely stating your visions and expectations is more efficient than mentoring individually, given the manpower situation.
  • I certainly don’t want any one person to become gatekeeper for any one area of contribution. A mentor role sounds to me like a gatekeeper role when you describe it the way you do, e.g. as a role that also says whether a contribution is desired or not.
  • The more responsibility you place on individual core team members, the higher the (already VERY high) barrier is to become a core team member, and the harder you will find it to actually solve the manpower situation.
  • If you assign special areas of interest, you may easily find yourself either dictating to team members what they must pay attention to - or having black holes where no attention is paid by design.

Again, sorry about the slight OT and meta - but you asked and I wanted to answer :wink:

2 Likes
#8

You are totally right Claus about the necessary time investment in that very specific case. I would maybe not take it as an example how to make things right, because reviewers (incl me) speed in way too late and a lot of work was done, which was reverted/diverted again later. I expect such a program to avoid exactly that. I believe that more time invested into planning saves a lot more time reviewing.

Personally I am not able to promise anything in the near future, so I am not available for this program at the time being.

#9

Hey everyone, hey Claus,

it’s not really OT as the discussion was meant to help solve the problem of how to ensure that all contributors have a chance to get reviews and no-ones effort is wasted in vain. Your points point to another possible solution, so that’s totally fine to discuss here :wink:

From reading your post, I thought I could at least make it a bit more transparent how I personally choose what to review and what I consider pre-requisites for core team members.

What do I review?
As I don’t work as a developer full time my day is fraught with interruptions via phone, meetings, people - so when reviewing while at work patches should meet the following criteria:

  • small / not too complex
  • well documented (how to reproduce, what’s the intended behaviour, why where decisions taken one way or the other)
  • ideally with tests
  • can be tested quickly and easily (in between interruptions so to speak)
  • already reviewed by someone else (so I can merge if the patch is ok)
  • actively reviewed by someone in my project team (we have a review session with some neusta developers every Monday)

When reviewing at home (or before 9 o’clock) I choose based on:

  • area that interests me / that I know something about
  • patch that I consider important (be it marketing wise for TYPO3 as a whole or business wise for our projects)
  • no obvious parts missing (rst files, docs, tests…)

And then there are additional cases where I can nearly always be convinced to review something:

  • the patch is from someone I trust / am friends with (which might not be an ideal criterion but I’m trying to be as honest as possible here)
  • I was asked to review the patch (with the same stipulation, the closer I am to the person that’s asking the faster they’ll get the review)

That’s basically how I choose what to review and hopefully makes that part more transparent.

Now on to the second part important for an answer, what do I consider important for becoming a core team member. Again the disclaimer: This is just my personal opinion and in no way meant as a general criteria listing.

Pre-Requisites Development

  • Good grasp of current development techniques / architectural knowledge
  • Knows the TYPO3 core well and is able to consider implication of changes
  • Continuously delivers high quality code without regressions
  • If there was a regression introduced, handles the fixing / mitigation responsibly and fast
  • Has backwards compatibility in mind when writing code
  • Takes care of surrounding tasks like documentation updates

Pre-Requisites Soft-Skills

  • Is able to work well in a team
  • Is able to leave ego out of discussions
  • Is able to compromise and follow the decisions of others
  • Will work toward a common goal - making TYPO3 better for current and future users
  • Does consider more than his/her own use case
  • Is aware of the impact of changes to the eco system
  • Feels responsible for not only his/her own code but also for the state of the system as a whole
  • Willingnes to help others
  • Empathy
  • Regular participation in hangouts/meetings/real-life events

That’s my list (for now, I probably forgot half of it, because some of these - especially on the social side of things - depend a lot on the situation).

Why do I write this novel? Because in my opinion there currently aren’t any contributors that already have the level I’d expect of a core team member, neither socially nor from a development perspective. That may be because the feedback is missing, but at this particular moment in time, I don’t see a way to add new members to the team fast - that’s why I’m searching for an alternative solution to lead / mentor contributors more actively, so they might fulfil these criteria in the future.

For the vision / expectations part: Yes, we should communicate more about the direction we want to go - I’m putting that on my list of things to consider / schedule. But: Not for every area there already is a vision. Take your caching efforts (that was you, wasn’t it?): For me, the current caching framework does it’s job well enough (not saying it can’t be better, but it’s fine to me as it is), so I’ll probably not put in any effort in that area as from my POV there are vastly more important areas to tackle in TYPO3. I don’t think there is an overall core team vision for that area of the core, maybe just because it isn’t a priority right now. But still, you did all that work there and it would be sad, if that effort you put in just got lost. Communicating an overall strategy that simply says nothing about caching would not help in this case - mentoring would in my opinion.

Ok, that’s far longer than I wanted to answer, but I hope it clears up some points and makes it a bit more transparent to everyone.

Thanks for reading :wink:

1 Like
#10

This topic was automatically closed after 28 days. New replies are no longer allowed.

#11

As there was low interest in this topic I will not follow-up on it with a voting phase but instead close it down. If someone wants to continue solving these kind of problems please open a new topic.