Commitment and maintainer group size - Githubissues

RadicalFx / housekeeping

This repository is intended to keep track and manage all what is not code-related. Requirements and Pre-Requirements discussions should be handled here too.

https://waffle.io/radicalfx/housekeeping

0 stars 1 forks source link

Commitment and maintainer group size #45

Closed mauroservienti closed 4 years ago

mauroservienti commented 8 years ago

At the time of this writing we have 12 pending PRs among which some quite old.

Obviously due to the fact that Radical is not our main focus, unfortunately we need to work as well, it is sometimes hard to commit, this is obviously complicated by the fact that the maintainer group is super small (@micdenny and I) and the we cannot merge our own PRs rule is causing some pain.

I actually see two possible approaches:

Find and introduce at least one new maintainer. Super complex, reviewing other PRs requires great skills and requires deep knowledge of the framework itself. We can, however we need to take into account that it might take a lot of time
put in place some W.I.P e.g. not more than 4 items in progress over the entire toolkit and at the same time try to enforce some commitment e.g. a PR should be reviewed within 3 days (whatever number we come up with is good)

@micdenny comments? thoughts?

mauroservienti commented 8 years ago

put in place some W.I.P e.g. not more than 4 items in progress over the entire toolkit

Another option could be to use story points as WIP, what waffle.io calls size, this could be interesting cause it requires some effort at the Ready stage to determine the size/effort required and can be used similar to the usage of velocity done by Scrum

mauroservienti commented 8 years ago

over the entire toolkit

Means that in this board https://waffle.io/radicalfx/housekeeping the WIP limit will be applied to the In progress column.

micdenny commented 8 years ago

yes this could become frustrating, because the PR committer is super exited of its function and would like to have a fast review so to be productive and eventually re-iterating fast, but as far as I saw in OSS developing this is an easy to fall-in condition, especially as you said when no one of the team are mostly committed on the project, and I think this is the problem, but to avoid such a delay probably your idea, to avoid taking care of too much features at the same time, is a good approach, I'm not sure about the reviews in XX days, I mean what is the fallback? If the team does not commit in XX days what happen apart the public humiliation :smile: ?

mauroservienti commented 8 years ago

I'm not sure about the reviews in XX days, I mean what is the fallback? If the team does not commit in XX days what happen apart the public humiliation :smile: ?

Completely agree, worth nothing. I was just throwing ideas on the table trying to improve the situation. So, what about starting with the WIP limit?

micdenny commented 8 years ago

what about starting with the WIP limit?

that's ok to me, I would start simply doing it :) I mean we decide a limit then we try to follow it ;)

mauroservienti commented 8 years ago

What about 4? that could mean 2 each.

micdenny commented 8 years ago

ok 2 each! agreed

mauroservienti commented 8 years ago

We now have 9 in progress issues globally, most of them depends on the GitVersion migration, once the whole migration is done, I'll ping you were I think I'll need you.

micdenny commented 8 years ago

ok great, thank you!

mauroservienti commented 4 years ago

Not a thing we can really solve. Closing.