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