Proposal to Revive and Maintain Pr-Size-Labeler: Seeking Community Input

[johnlk]

I used this labeler in another company of mine years ago. It's a nice GH action which encourages smaller PRs, which leads to faster PR reviews, which leads to faster product velocity IMHO.

However, it seems like this project is not maintained anymore and there are a number of open, yet very fixable issues, including:

• Broken files to ignore option (Issue #67)
• GitHub API config value not working (Issue #27)
• Ignoring deleted line diffs option (Issue #66)

Additionally, during my recent attempts to set up the labeler on a project, I encountered several operational quirks, such as unreported errors leading to unlabelled PRs, which suggests issues are silently failing.

While I want to fork and maintain a new version of this repository, I will only do so if there are people that would consider it worth while for their teams and their projects.

For a bit of background, I've contributed to open source and have one other project I'm maintaining right now, Robin AI, which is another lightweight github action (58 stars). It also got some press: https://www.globenewswire.com/en/news-release/2023/06/22/2693172/0/en/New-Open-Source-Project-Uses-Artificial-Intelligence-to-Improve-Software-Code.html

That's it. React if you want to see this project pushed forward 🙏🏻

[JavierCane]

Hi @johnlk,

First thing first: Sorry for not providing the quality of support the community expected with this GitHub Action. We completely agree with you that the situation right now is far from what anyone could expect in terms of maintenance.

Said that and given your proposal on continuing the efforts of maintaining the project. Would you be interested into adding you as maintainer to the project?

We would like to compensate it with 20€/month sponsorship through GitHub Sponsorship program ensured during 12 months, and evaluate the relation after that.

We are willing to continue to support open source and think that the project base is good enough in order to iterate it with the contributions you mentioned.

Thanks for considering the proposal.

[johnlk]

Hi @johnlk,

First thing first: Sorry for not providing the quality of support the community expected with this GitHub Action. We completely agree with you that the situation right now is far from what anyone could expect in terms of maintenance.

Said that and given your proposal on continuing the efforts of maintaining the project. Would you be interested into adding you as maintainer to the project?

We would like to compensate it with 20€/month sponsorship through GitHub Sponsorship program ensured during 12 months, and evaluate the relation after that.

We are willing to continue to support open source and think that the project base is good enough in order to iterate it with the contributions you mentioned.

Thanks for considering the proposal.

@JavierCane, yes please add me as a maintainer and I can help get some of these open PRs merged or closed as soon as this week.

No need to compensate in any way!

Are there any contribution guides? This might be one of the first things I work on. For example, my request to start failing the action on errors could be perceived as a fundamental change.

[JavierCane]

Thanks for your comprehension and willingness to help @johnlk 😊

Right now we do not have a contribution guide. Feel free to propose one and we could review it to set the collaboration expectations and so on. We are eager to revive the project, and our only concerns that would have to be included in the contribution guide are:

• Maintaining a MIT license in the project and all contributions
• Respecting Semantic Versioning while adding new fixes and features. That is, regarding your concern of introducing the "start failing the action on errors" behaviour change, yes, we also understand it as a fundamental change, but there is no problem going forward with it as we:
  1. Discussed it openly before making a decision (right in this thread, no unnecessary bureaucracy)
  2. Agree to introduce it (we agree that it would be beneficial to do so) publishing a new major version showing that the GitHub Action it is no longer the backward compatible in terms of the public contract or assumptions that current users might have made
• Maintain a minimum code quality. We do not want to be too picky about this, just understand this as the willingness to follow the already existing in the code base patterns. That is: short functions with clear purpose and naming and separate functions by modules/namespaces (github, ensure…)

What do you think?

Thanks!

[johnlk]

Thanks for your comprehension and willingness to help @johnlk 😊

Right now we do not have a contribution guide. Feel free to propose one and we could review it to set the collaboration expectations and so on. We are eager to revive the project, and our only concerns that would have to be included in the contribution guide are:

• Maintaining a MIT license in the project and all contributions

• Respecting Semantic Versioning while adding new fixes and features. That is, regarding your concern of introducing the "start failing the action on errors" behaviour change, yes, we also understand it as a fundamental change, but there is no problem going forward with it as we:

  1. Discussed it openly before making a decision (right in this thread, no unnecessary bureaucracy)
  2. Agree to introduce it (we agree that it would be beneficial to do so) publishing a new major version showing that the GitHub Action it is no longer the backward compatible in terms of the public contract or assumptions that current users might have made

• Maintain a minimum code quality. We do not want to be too picky about this, just understand this as the willingness to follow the already existing in the code base patterns. That is: short functions with clear purpose and naming and separate functions by modules/namespaces (github, ensure…)

What do you think?

Thanks!

That's a great start for the contribution guide. We can maybe flesh out a little more what constitutes a minor version number bump vs a major version bump, but this is a great start.

On this particular change, or any potentially controversial change, we can also introduce an optional param defaulted to false. Something like fail_action_on_error: false for this particular example.

If you add me as a maintainer, I can start addressing open PRs starting this week.

Thanks!

[JavierCane]

Hi @johnlk!

1. Write permissions enabled for you in the repository 😊
2. Yup, your proposal of maintaining backward compatibility though parametrizing that option with a default value equal to the current behaviour would be even better than forcing to update to a major version, so it seems we are on the same page regarding these kind of changes ✨

If you need to contact us, you also have the email address: opensource@codely.com

Thanks for your contributions!