search

srobo / dev-team-proposal

Proposal for the Dev Team
0 stars 0 forks source link

Interaction with incumbent maintainers #3

Open PeterJCLaw opened 5 years ago

PeterJCLaw commented 5 years ago

From https://github.com/srobo/dev-team-proposal/pull/1#issuecomment-470288736:

A separate thought has just occurred to me -- we have quite a lot of repos which have their own issue trackers (and in some cases sort-of incumbent maintainers). We should consider how those would interact with the Dev Team.

Do we expect all bug fixes to go via the Dev Team? Would we allow for a continuation of the current setup with maintainers? I'm not sure that this needs to be completely solved now, though we should definitely aim to recognise those already in these roles and not displace them unnecessarily.

trickeydan commented 5 years ago

Project Groups essentially maintain the repos independently, and then the Dev Team recommends versions to the Core Team.

Do we expect all bug fixes to go via the Dev Team?

No. That would be a waste of time. The Dev Team is more of an oversight.

Would we allow for a continuation of the current setup with maintainers?

Yes. e.g SRComp could be an entirely separate project, but there could be a SRComp 'working group' project group within SR that contributes to it. This is the model that I am aiming for with j5

PeterJCLaw commented 5 years ago

I think you've possibly misunderstood my question around maintainers -- I was thinking more of internal SR projects (i.e: things which no-one else uses) such as the IDE and nemesis.

RealOrangeOne commented 5 years ago

Project Groups essentially maintain the repos independently

This model works fine when initially developing a repo, but fails for future development. If a project group wants to refactor an item (eg board firmware), where that group is different to the group which originally developed the repo, they may approach the original project group over the dev team.

RE bug fixes, I don't think we can flat out block bug fixes from coming through the dev team as your comment suggests. Many bug fixes require a partial re-development of a feature, which is definitely something we want to come through the dev team. We may need to define a threshold for this, or put it down to common sense. Although I suspect the fact that a person may question whether they need to go through the dev team vs just open a PR (which is an exponential increase in friction), which may deter people.

trickeydan commented 5 years ago

refactor an item (eg board firmware)

That sounds pretty major, would require a spec anyway.