State of maintainership?

[leoarnold]

This gem has not released since 2015 and has not seen a commit since 2017. The community seems to be wondering about the current state of affairs.

@pointlessone & @packetmonkey You seem to be the last people who merged changes on this project. Do you have an info on this topic?

[pointlessone]

You can consider this project feature stable. It is by no mean perfect and contributions are welcome but other then that it does what it was designed to do and does it fairly well for the majority of the most common use cases.

Also I'm not the maintainer of this project. This project has its own maintainers. However, I think my statement reflects their position at least to some degree.

[leoarnold]

Thanks for the quick answer. I guess it's better to leave this issue open, so others will find it.

[leoarnold]

This project has its own maintainers.

@pointlessone Are you sure? The latest reaction of a maintainer to a PR I was able to find was by yourself in 2018 #103 (review)

[petergoldstein]

@pointlessone who are the maintainers? There are a few items that it would be really good to see addressed. Not so much feature changes as basic maintenance

It would be nice to see:

1. @leoarnold 's PR Fix build setup and pivot to GitHub Actions #131 merged to get CI running again
2. Add Ruby 3.1 to that CI matrix and address any issues

Given that there are libraries out there that have dependencies on this gem (i.e. https://github.com/excid3/receipts), it would be good to get CI running at a minimum.

[pointlessone]

I maintain prawn, pdf-core, and ttfunk. I have the gem push bit so, I guess, I'm the official maintainer. There were other people who helped with reviews, bugfixes, and responses but they probably moved on by now.

A while back I posted a status update going a bit into the state of maintainership. You can be the next prawn-table maintainer if you want to.

Meanwhile, I will look into tending to prawn-table.

[johnnyshields]

👍 +1 to getting an additional maintainer on all prawn libs who can move things forward.

[petergoldstein]

@pointlessone I just responded to your update. I'm up for helping as a maintainer. Just let me know.

[pointlessone]

No one needs my permission or blessing to start helping out. The more community can do without everything revolving around me the better.

I also expect that at some level you understand that I won't give away repo/rubygems access left and right. Let's know each other a little bit better before we do that. Please bear with my trust issues towards people I met on the internet and exchanged like 5 messages with them. 🙂

I'm all for expanding the maintainers team but how am I to do that if I don't see anyone doing much, showing their interest in the position and building trust with the community?

[petergoldstein]

@pointlessone Sure. Let me put it this way then - what would be most helpful for you at this point? A couple of thoughts:

I can submit PRs - especially on CI issues. For example:

• I've just submitted a PR to pdf-core to add Ruby 3.1 and get CI green again. Looks like you merged it.
• I can submit PRs against all repos to address this comment, as pull_request is the standard configuration.

I can review PRs and (ideally) label those that are blocked on maintainer action, should likely be included in the next release, or require a greater knowledge of Prawn internal than I can provide at this time. I can't label issues, but I can mark with a comment.

You're saying you need help and don't have the time, etc. to dedicate to Prawn to resolve all the outstanding issues. Totally reasonable. So what specific things can a potential contributor do to help without maintainer level access on one or more repos that would help i) get outstanding issues and PRs addresses and closed/merged and ii) drive towards gem releases that include resolution for the issues reported by the community?

[pointlessone]

All of the above please. 🙂 PR review, issue triage, bugfixes when issues are real. Everything is helpful and will be greatly appreciated. If I can come in and hit Merge button a few times knowing that PRs are in a great shape we won't see them sitting waiting for when I have a decent amount of time to get into code. And when I'm confident that master is in a great shape cutting a release won't be as daunting a task as it is right now.

[gettalong]

@petergoldstein I help out when I have time and spent some of it the last few days with looking at and closing issues as well as pull requests. Feel free to tag me in an issue/PR if you need more insight regarding internals since I have a decent amount of knowledge or just a second opinion.

[petergoldstein]

Thanks @gettalong , will do.

[johnnyshields]

@pointlessone just my two cents (as a CTO/Founder whose business uses Prawn heavily):

1. "Must have": Prawn maintainer who is able to release patches to meet basic security (CVE) and community needs (Ruby 3.1 support, etc.)
2. "Nice-to-have": More community reviews on feature enhancement, etc. PRs.

I propose to de-couple these two concerns. For (1) though I've never met/worked with Peter, I see he is the maintainer of the widely-used Dalli gem, and for this reason would be a good pick for Prawn maintainer (with Rubygems, etc. credentials.) While I fully respect that it's your call, I personally don't believe that having him triage a few PRs first is necessary to further "vet" him.

[pointlessone]

Those are indeed different concerns. But 1 is also a two different concerns. Adding a new ruby to the CI matrix (and maybe fixing compatibility issues on the language level) is not a very hard task. Addressing CVEs is a different story. I don't doubt Peter's qualification as Dalli maintainer but he himself admitted that he's not very familiar with both Prawn codebase and PDF. His forthcoming is admirable and his recent activity in the community is appreciated.

I also have to repeat myself: a maintainer will be promoted from an active community member. Not appointed in hope they will become active and proficient down the line. So from (2) comes (1).

I'm deeply convinced that a maintainer has to be at least somewhat familiar with the codebase they maintain and the problem domain the codebase deals with. PR triage is not indicative of any of those but I need to gauge that somehow so the must be some visibility and without any activity in the community I have no way to do that.