Hi David, Thanks for this proposal. I agree that this is something we can strive to do better in the Flink community, and I would be keen to help out here.
+1 to the suggestion for a recurring working group meeting to triage and assign PRs. I think the suggestions we have on the thread are great, but can be explored independently! 1. Review open PRs. We could simply get started by sorting by updated date in descending order (LIFO ensures we are looking at the freshest ones), or choosing a particular component https://github.com/apache/flink/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc 2. Bot to followup on stale PRs, and close them if not needed. Side note: Also did some analysis of the PRs by labels, and attached the data below. I imagine we could close out the Documentation ones quite quickly! Regards, Hong Open PRs as of (2024-11-07) by label. review=description? : 275 component=TableSQL/Planner : 138 component=TableSQL/API : 109 component=Documentation : 90 component=<none> : 70 component=Runtime/StateBackends : 54 component=Runtime/Coordination : 44 component=chinese-translation : 41 component=TableSQL/Runtime : 39 component=Formats : 37 component=Connectors/Hive : 36 component=API/DataStream : 32 component=Runtime/Checkpointing : 32 component=Tests : 29 component=Deployment/Kubernetes : 25 component=Connectors/FileSystem : 24 component=Connectors/Common : 21 component=API/Core : 20 component=Runtime/WebFrontend : 20 component=TableSQL/Ecosystem : 19 component=Runtime/Task : 17 dependencies : 16 component=API/Python : 15 component=FileSystems : 15 component=TableSQL/Client : 15 component=Runtime/REST : 14 component=Deployment/YARN : 13 component=Runtime/Metrics : 13 component=BuildSystem/CI : 12 component=API/TypeSerializationSystem : 11 component=Client/JobSubmission : 11 component=Runtime/Configuration : 11 component=BuildSystem : 9 component=Library/CEP : 8 java : 8 javascript : 8 component=CommandLineClient : 7 component=Connectors/HBase : 6 component=Runtime/Network : 6 component=Connectors/Kafka : 5 component=Connectors/Kinesis : 5 component=TestInfrastructure : 5 component=Connectors/HadoopCompatibility : 4 component=Deployment/Scripts : 4 component=API/DataSet : 3 component=Connectors/Cassandra : 3 component=TableSQL/LegacyPlanner : 3 review=consensus? : 3 component=Connectors/GoogleCloudPubSub : 2 component=Connectors/Pulsar : 2 component=Examples : 2 component=API/Scala : 1 component=BuildSystem/AzurePipelines : 1 component=BuildSystem/Shaded : 1 component=Documentation/Training : 1 component=flink-docker : 1 component=ProjectWebsite : 1 component=Runtime/QueryableState : 1 post-ui-rework : 1 On Thu, Nov 7, 2024 at 5:06 AM Lyrics Cool <ktanu1...@gmail.com> wrote: > Hello David, > > I believe this is a valuable initiative that will significantly enhance the > codebase as well. I would also like to join this group and contribute to > the community. > > Regards, > Anu K T > > On Mon, Nov 4, 2024 at 8:36 PM David Radley <david_rad...@uk.ibm.com> > wrote: > > > Hello, > > I have been looking at the Flink Jira and git. I see a large number of > > Flink Jira issues that are open and critical or blockers > > > https://issues.apache.org/jira/browse/FLINK-36655?jql=project%20%3D%20FLINK%20AND%20priority%20in%20(Blocker%2C%20Critical) > > I realise some of these issues may not actually be critical as they have > > been labelled by the submitter. > > > > I see 1239 open unmerged PRs > > https://github.com/apache/flink/pulls?q=is%3Apr+is%3Aopen. Some of these > > are not associated with assigned issues, so may never be merged. This > > amount of unmerged PRs, means that many people have put a lot of time and > > effort into creating code that has not made it into the codebase, so they > > do not get the credit for the contribution, which must be disheartening > and > > the codebase does not get the benefit of the contribution. > > > > This is a large amount of technical debt. I would like to help address > > this problem by setting up a workgroup, with others in the community who > > would like this addressed. The scope of the workgroup would be to improve > > these numbers by activities such as: > > > > * Triaging PRs so it is easier for committers to merge or close them. > > * Identifying prs that could be closed out as no longer relevant. > > * Getting committer buy in. > > > > Are there other ideas from the community around how this could be > improved > > with or without a workgroup, or whether the existing processes should be > > sufficient or enhanced? > > > > Is there an appetite to address this in the community? I am happy to > drive > > this as a community workgroup, with my team in IBM, if there is community > > support. > > > > We could call the community workgroup ?Community Health Initiative? CHI > to > > energise the Flink community. > > > > WDYT? > > > > Kind regards, David. > > > > Unless otherwise stated above: > > > > IBM United Kingdom Limited > > Registered in England and Wales with number 741598 > > Registered office: Building C, IBM Hursley Office, Hursley Park Road, > > Winchester, Hampshire SO21 2JN > > >
