Call for additional Mapster maintainers

[andrerav]

Hi Mapster community,

2024 was rough year. In february, I unexpectedly lost a close family member. I have to admit that this has been tough to deal with on a personal level. Unfortunately, this indirectly affected Mapster, and for that I apologize. As the sole maintainer, I simply haven't been able to keep up with incoming issues, pull requests and getting the contributions pushed out to new releases. In short -- being a single maintainer simply doesn't scale well, and especially when times get tough. So, to ensure that Mapster remains a reliable and up-to-date tool for the .NET community, I’m now looking for additional maintainers to join the project.

Typical responsibilities may include:

• Pull Requests: Reviewing contributions, providing constructive feedback, and merging approved changes.
• Issues: Triaging new issues and, to the extent possible, resolving existing issues.
• Releases: Maintain a reasonable release cycle that meets community expectations.
• Code quality: Continuously improve the code quality.
• New features: Nominate and implement new ideas and features.
• Documentation: Improving clarity, fixing typos, and keeping the wiki up to date.
• Community: Engaging in discussions and questions and fostering collaboration and contributions.

If you have the time and interest, I’d love to hear from you. This invitation is open to anyone passionate about Mapster and open source collaboration. Selection criteria will prioritize relevant skills and past contributions to the project. I am hoping we can onboard at least 2 additional maintainers.

I will of course remain as a maintainer myself and continue to help out as much as I can :)

Please reach out via email at [email protected] to express your interest.

[andrerav]

I hope that @DocSvartz and @stagep will read this and give it a think :)

[devgopher]

Please accept my condolences, @andrerav

[iAmBipinPaul]

sorry for your loss @andrerav 🙏
if possible, please post this on dotnet reddit.
https://www.reddit.com/r/dotnet/

[DocSvartz]

I’m sorry for your loss @andrerav .

I can join Mapster maintainers. But at about the current level as I do it now.

In these areas I most likely cannot help:

Releases: Maintain a reasonable release cycle that meets community expectations.
Code quality: Continuously improve the code quality.

[andrerav]

That's great to hear @DocSvartz :) @stagep has also confirmed that he will step up. I have added you both to the organization and assigned appropriate roles. Should we keep all discussion on this board, or would you prefer a public Discord server to discuss next steps?

[stagep]

Let's keep the discussion here in the repo. We can start a new discussion that deals with the overall direction or just continue it here in this discussion. I spent the last couple of days looking at a range of issues. Some are old and may already be addressed and / or no longer relevant. I would like to close a lot of issues with a comment that if the issue is still active and unresolved then reopen the issue. Alternatively, we do the opposite and comment that this issue will be closed in 7 days unless there is a response back that it is still an issue. Do you have a preference @andrerav ?

[DocSvartz]

@stagep OK

[DocSvartz]

I plan to work on #755 and #723 please don't close them.)

[stagep]

Anything with recent activity will not be closed. I will focus on dormant issues to start.

[stagep]

Do you like the following comment on closing issues:

In order to identify issues that are still active, we are closing issues that we believe are either resolved or are dormant. If your issue is still active then please reopen. Thanks.

[andrerav]

Yep, looks good to me :)

[DocSvartz]

@andrerav @stagep I would like to agree on the format of communication between Maintainers
For example:
In case of agreement, is it enough to put a reaction 👍 or should always give a text response?

[andrerav]

Both are fine with me, just keep in mind that thumbs up won't give the other party a notification in the app or by email :)

[stagep]

I wanted to give @andrerav and @DocSvartz an update. After closing the issues that were old or appeared to be resolved, I decided to look at a recent issue #737. I was overwhelmed trying to understand the code and it was just too much cognitive load on top of the projects that I am currently working on for my job. As a solo full stack developer on a business application, I wear many hats and Mapster was one hat too many. I continue to monitor issues to do with configuration and usage of the library, although (ironically) there have not been any simpler issues recently. I would like to thank both of you for your continued work on this library.

[DocSvartz]

@stagep you inspired me by dealing with issues so quickly 👍👍👍
Regarding #737, at first I thought it shouldn't work )
But as far as I understand there is no particular problem there. I wrote my thoughts on this matter under isuue.

If you worked on implementing caching as part of the issue, I don't think there is an easy task.

[stagep]

@andrerav There are 3 issues that I believe are all discussing the same idea. #377 #451 and #622 . If they are the same issue then I would like to close #377 and #451 as duplicates. Please let me know.

[andrerav]

@stagep I agree, feel free to close them as duplicates of #622 :)

[reichigo]

I'm very sorry for your loss. If you'd like, I can join and try to help.

[DocSvartz]

@andrerav @stagep

Perhaps we should define a list of priority issues for the next release?

Just developing a solution and testing them at the same time (including developing the tests themselves) takes a lot of time.

Leave them here and I'll give you feedback. Will I be able to solve them before the release or not :)

[stagep]

@andrerav @DocSvartz

I was working on an issue with Mapster.Tools not working with .Net 8/9 in the development branch and so tested the master branch using .Net8/9 but forgot I was not on a fork and pushed my changes to the repo. I just reverted to the prior commit so master is back to how it was.

[DocSvartz]

Maybe the next prerelease should be released, at least with some new PRs.
@andrerav @stagep what do you think about it?

[stagep]

Yes on a prerelease. Perhaps one prerelease on all the simpler fixes that are very likely to be non-breaking, and one prerelease on all the null / mapping issues. We have got out of a steady prerelease package and need to at least provide packages. Even I am using my own fork and would like to move to a prerelease.

[DocSvartz]

@stagep Maybe I've already forgotten :) But in terms of null mapping issues there seem to be no significant changes.
The most significant change is related to the use of default values ​​and PRs based on it.

I can mark PRs as something like NextPre and NextPre+

[stagep]

@DocSvartz perhaps just all on the same prerelease then just to get a prerelease out there. It's a bit of a catch 22. Not prereleasing frequently makes each prerelease have more changes, which could have more breaking changes.

[DocSvartz]

Yes, if count of current PRs is too large for one prerelease.

[DocSvartz]

I think it will be easier to catch bugs if it arise.
The rest of the commits are mostly fixes. Or improvements in one specific context.

[DocSvartz]

I meant this distribution in prereleases:

1. all PRs without (# 769, # 774 and # 778)
2. 1 + PRs (# 769, # 774 and # 778)

[DocSvartz]

@andrerav I have collected my PRs into two branches as I wrote earlier. The tests pass without errors. If necessary, I can add them as separate PRs.

[DocSvartz]

@andrerav @stagep I think I figured out how to publish all this :)
If necessary, I can try to get busy releasing new versions.

[DocSvartz]

@andrerav Please answer something about this issue #802.

[DocSvartz]

@andrerav I can do pre-releases if you agree.