Closed mindthegab closed 4 years ago
bingenito
commented
4 years ago For anyone looking for the formatted markdown of this PR to make it easier to initially read, here is a link directly to the branch file - https://github.com/finos/finos-pmcs/blob/program-removal-rfc/rfcs/202001-rfc-program-removal.md
rikoe
commented
4 years ago @bingenito you can also view from the PR by using the "Rich Diff" feature:
This is how to enable it:
rikoe
commented
4 years ago I would like to request that the new proposal for project at the top level still support the idea of multiple "working groups" or "teams" per project, which would correspond to different sub-teams that cover particular disciplines.
E.g. in FDC3, we are working on the same project, and in the same repository in GitHub, but the "API team" and the "Use Case team" have separate meeting times and mailing lists, as not everything covered in every meeting is relevant for everyone.
I view this as, for example during a large software development project, while one project, you might have multiple chat channels/email groups, e.g. for the UI team, the server team and the DevOps team.
I expect this to be the exception, not the rule, but it will be great if the new project model can support such a structure, even if it is mostly self-governed by each project. I think the easiest way to accomplish this is via GitHub sub-teams for the project, and email/chat setup to correspond to the GitHub teams.
tschady
commented
4 years ago Initial thoughts:
I think you'll be deleting a natural scaffold for community. Program cultures might need more time to grow. I understand your conclusions on the 'con' side, but I think you've seen these because the overwhelming focus from the FINOS organization has been on bureaucracy, not solving problems or focusing on growth. I hope this doesn't sound harsh, I think the evidence supports my position: just look at the agendas for every pan-PMC meeting and you'll see they are 90% hygiene and bookkeeping. We're quite close to some good ideas - the recent 'roadmap delta' idea for the board meeting has potential.
My overhead as a PMC lead is almost nil. What little there is could be automated away with an expansion of the metadata-tool and an extra dotfile in each project.
I think doing away with this layer is going to have costs you are not predicting or ready for: it would not affect my day-to-day or that of the projects I'm in (besides perhaps increasing delays for administrivia), but I do think there will be a loss of potential community development.
I suppose a collection of projects could voluntarily organize under an unofficial program banner if they thought it furthered their goals.
I do think there needs to be a change: I would jettison the focus on bookkeeping, however comforting, and instead talk about setting up an environment where experimentation thrives, and good software comes out the other side. Communities enable that. You can't force a community through official Program decree, but I think it might help.
mindthegab
commented
4 years ago Hey @rikoe - I created https://github.com/finos/finos-pmcs/issues/23 to track this. We are actually meeting in 6m from now to discuss exactly this /cc @brooklynrob @mcleo-d and we'll report back.
I would like to request that the new proposal for project at the top level still support the idea of multiple "working groups" or "teams" per project, which would correspond to different sub-teams that cover particular disciplines.
E.g. in FDC3, we are working on the same project, and in the same repository in GitHub, but the "API team" and the "Use Case team" have separate meeting times and mailing lists, as not everything covered in every meeting is relevant for everyone.
I view this as, for example during a large software development project, while one project, you might have multiple chat channels/email groups, e.g. for the UI team, the server team and the DevOps team.
I expect this to be the exception, not the rule, but it will be great if the new project model can support such a structure, even if it is mostly self-governed by each project. I think the easiest way to accomplish this is via GitHub sub-teams for the project, and email/chat setup to correspond to the GitHub teams.
I would like to request that the new proposal for project at the top level still support the idea of multiple "working groups" or "teams" per project, which would correspond to different sub-teams that cover particular disciplines.
E.g. in FDC3, we are working on the same project, and in the same repository in GitHub, but the "API team" and the "Use Case team" have separate meeting times and mailing lists, as not everything covered in every meeting is relevant for everyone.
I view this as, for example during a large software development project, while one project, you might have multiple chat channels/email groups, e.g. for the UI team, the server team and the DevOps team.
I expect this to be the exception, not the rule, but it will be great if the new project model can support such a structure, even if it is mostly self-governed by each project. I think the easiest way to accomplish this is via GitHub sub-teams for the project, and email/chat setup to correspond to the GitHub teams.
mindthegab
commented
4 years ago Hey @tschady,
thanks again for such a thorough review. This is exactly the type of deep engagement we'd love all our PMC Members and Community leaders to have.
See my answers interleaved:
Initial thoughts:
I think you'll be deleting a natural scaffold for community. Program cultures might need more time to grow. I understand your conclusions on the 'con' side, but I think you've seen these because the overwhelming focus from the FINOS organization has been on bureaucracy, not solving problems or focusing on growth.
This is exactly what we are trying to change. Remove governance overhead and governance structures which to date have proven to create a LOT of work - in part for PMCs but mostly for the FINOS team - and provide a streamlined process whereby new projects can come in the Foundation quickly to experiment, without having to:
I hope this doesn't sound harsh, I think the evidence supports my position: just look at the agendas for every pan-PMC meeting and you'll see they are 90% hygiene and bookkeeping. We're quite close to some good ideas - the recent 'roadmap delta' idea for the board meeting has potential.
My overhead as a PMC lead is almost nil. What little there is could be automated away with an expansion of the
metadata-tooland an extra dotfile in each project.
You are the model PMC member, unfortunately there's only 1 or 2 programs which are in this situation.
I think doing away with this layer is going to have costs you are not predicting or ready for: it would not affect my day-to-day or that of the projects I'm in (besides perhaps increasing delays for administrivia), but I do think there will be a loss of potential community development.
I suppose a collection of projects could voluntarily organize under an unofficial program banner if they thought it furthered their goals.
I agree with that. We would reach out to the community to define what the taxonomy is to improve discoverability. It's important to have some kind of grouping, but we found that a one dimensional highly partitioned space is more of an issue for community development than any advantage (for example, we have seen very little evidence of PMCs actually feeling partly responsible for growing their program.
I do think there needs to be a change: I would jettison the focus on bookkeeping, however comforting, and instead talk about setting up an environment where experimentation thrives, and good software comes out the other side. Communities enable that. You can't force a community through official Program decree, but I think it might help.
I think we are fully aligned on intents. That was our view 2 years ago when we put together the program construct, but despite several efforts to train, document and provide federated governance, unfortunately at this point programs have proven to be more of a burden (again mostly for the FINOS team, which is constantly prodding, nudging and going after PMCs - also creating a negative dynamic, a vicious circle we ought to break).
I'd be happy to get on a call with you to walk you through this proposal which received overwhelming support from the Board and how we can improve it.
rikoe
commented
4 years ago As in all things, it is helpful to look at where others have already forged a path. I really like the following:
https://landscape.cncf.io/format=card-mode&project=hosted
The Cloud Native Computing Foundation has one top-level construct - projects - and a status of Graduated, Incubating and Sandbox. Nice and simple, and website like the above make it really easy to navigate and discover projects.
However, you will note that there isn't necessarily a one-to-one relationship between CNCF "projects" and a single GitHub repository. E.g. fluentd has its own GitHub organisation: https://github.com/fluent.
I think simplicity and discoverability is key, as is flexibility. We don't want to put people off with process or rules.
"The process should work for us, we shouldn't work for the process."
mindthegab
commented
4 years ago 100% agreed. My answers below:
As in all things, it is helpful to look at where others have already forged a path. I really like the following:
Our project catalog was largely modeled around that https://finos.github.io/?sort=hotness-down and we are planning improvements in Q1/Q2.
The Cloud Native Computing Foundation has one top-level construct - projects - and a status of Graduated, Incubating and Sandbox. Nice and simple, and website like the above make it really easy to navigate and discover projects. That's what we are going after.
However, you will note that there isn't necessarily a one-to-one relationship between CNCF "projects" and a single GitHub repository. E.g. fluentd has its own GitHub organisation: https://github.com/fluent.
That is already supported in FINOS. One FINOS project can already have multiple repositories. See for example "Hadouken" or "Symphony Java Client" who have 2 repositories per project. So I think we are 100% aligned here.
I think simplicity and discoverability is key, as is flexibility. We don't want to put people off with process or rules.
The goal here would be to define a multidimensional (e.g. "user centric" or "tech centric") taxonomy of projects and keep discoverability high vs having a single highly partitioned program taxonomy - which was never meant to be a "messaging" framework (and creates hurdles for new contributors in an industry new to open source) but a governance structure (which largely hasn't worked).
"The process should work for us, we shouldn't work for the process."
mindthegab
commented
4 years ago As an update, the Board has NOT discussed this topic at the last Board meeting and so I have extended the RFC for another 15 days to allow for more collaboration.
mindthegab
commented
4 years ago Dear PMCs and especially @tschady @rikoe @jbjonesjr @nkolba @bingenito,
thank for chiming in here.
In response to:
1) Your feedback on this issue 2) The changed market conditions with COVID-19 and the need to even more double-down on value delivery and defocus on governance
I have slightly modified this proposal and the related one to introduce a TAC (Technical Advisory Council) which I presented to the Pan-PMC meeting on 3-31 and plan to bring a consolidated proposal to the Board at our meeting tomorrow after having reviewed it with the Membership & Governance Committee.
I'm attaching a detailed set of slides which I'll present to the Board tomorrow (also available on Google Slides here), but will recap the highlights here before closing this RFC:
We will be moving to "deprecate" (as opposed to "remove") Programs: This means no new Programs will be spun up and that existing Programs will be asked if they want to continue operating as Programs or disband and turn into one or more top level Projects. This "softer" approach will allow of us to slow-roll this change and also to take enough time to evaluate replacement options like a TAC, while existing governance will still be in place and so we can all focus on delivering value/innovation instead of having a massive load to update all of our public documentation. This slide shows a potential recommendation how existing programs can morph but of course we'll work with each of you to decide the best course of action.
If there's general consensus tomorrow, over the next quarter we'll work with identify charter, initial deliverables and a roster for a technical advisory committee. This appendix shows a potential proposal, but again we'll work openly with the Community to understand value and how to make the TAC most effective before starting it.
In the meanwhile, per our previous discussions, the FINOS officers will seek tomorrow authority to approve new (program-less) Projects and transition them through the lifecycle based on objective criteria, as well as to work with Programs to wind down those who choose to do so without requiring piece meal Board approval. If then the TAC is approved some responsibilities can be moved to the TAC at a later stage, but we expect this will streamline the process and have the FINOS team focus on governance while the Community can focus on delivering valuable solutions to pan-industry issues. Of course we as FINOS team have the best interest in seeking advise from Board (and TAC if its gets created) and any of you will always be able to appeal to the Board in case there's any concern with FINOS decisions.
I will proceed with closing this RFC and again thanking you for your very useful feedback here. And hope you like this middle-ground proposal, which effectively allows Programs that choose so to continue operating if they see value in it, while we look forward to a less onerous and more streamlined way of governing our Community.
2020Q2 - FINOS Program Deprecation proposal - For Board.pdf
/cc @brooklynrob @toshaellison @maoo @mcleo-d @aitana16
Dear PMCs and Community,
as presented over the last 2 Pan-PMC meetings, the Board has discussed in October a proposal to simplify the FINOS Governance with the goal of reducing overhead for contributors and community leaders, while enabling the FINOS team to efficiently grow the community through a simplified message and process, also based on objective criteria defined by with the previous RFCs approved last year (the Project Lifecycle revision).
Please post your feedback by:
This RFC is open until February 15th 2020.