search

bastibe / org-journal

A simple org-mode based journaling mode
BSD 3-Clause "New" or "Revised" License
1.25k stars 124 forks source link

Maintainership #400

Closed xeruf closed 9 months ago

xeruf commented 2 years ago

As @bastibe seems to have been busy/away for a few months now and there are quite a few bugs and PRs, I would like to ask how to move on here. Would you be open to adding co-maintainers to the repo? Should we move to an organization such as https://github.com/emacsorphanage or https://github.com/toemacs ? CC @tarsius @purcell

bastibe commented 2 years ago

I would absolutely be open to adding maintainers. Life is indeed very busy at the moment and leaves little room for active maintenance on this project.

I would prefer a simple co-maintainer on this repo instead of moving the repo to another organization entirely.

xeruf commented 2 years ago

So I would consider @dppdppd @jmay and myself due to recent contributions :) @dalanicolai also has two PRs up, idk if he might still be interested in joining again

jmay commented 2 years ago

Happy to help out in any way I can, I do have some time available. But my single contribution to the code was pretty minimal.

bastibe commented 2 years ago

Gladly! I'll grant commit rights to @jmay and @xeruf, and to @dppdppd as well if they so desire.

Since I've been in a situation like this before, it is a good idea at this time to think about how we'd like to collaborate.

I think it's generally a good idea to never commit to master, and to only merge pull requests if at least a second person has accepted it (barring time-critical bug fixes etc.). I also think it's a generally good idea to not have too many fixed rules to follow and keep things informal and personal 😁.

What do you think?

xeruf commented 2 years ago

Yes, totally agree, if there are more than two maintainers this is not a problem. I do think it is sensible to enable branch protection on master, preventing force pushes and requiring a PR review, all this can be added in the settings.

I guess we all will only contribute sporadically, but the point is that we do not have a single point of failure anymore :)

I have written https://kull.jfischer.org, maybe you find that useful :)

bastibe commented 2 years ago

Personally, I prefer social conventions over technological restrictions. As such, I am not generally a fan of git hooks or protected branches to enforce policy. I've found it more of a hindrance than a useful protection for professionals (although it is a good safety net for novice contributors).

Regardless, if you'd prefer a more rigid workflow, I won't stand in the way.

xeruf commented 2 years ago

that's fine with me - so are we already free to merge in reviewed code or would you like to still have a say there?

jmay commented 2 years ago

Agree with @bastibe. Until I know the codebase really well, I would not merge anything without discussion, but I don't like to set up elaborate control structures & systems before they are needed.

bastibe commented 2 years ago

Feel free to merge as you see fit! Of course you can always ping me if you'd like my input.

Most important of all, however, please do not feel pressured to "work" on org-journal. We're doing this for fun, and there is absolutely no obligation to respond to things quickly or at all. I've had my brush with burnout, and it's not worth it for anybody. When in doubt, it is perfectly acceptable to tell people to fix things on their own. Github is a platform for friendly collaboration, not work allocation.

jmay commented 1 year ago

@bastibe I'm happy to test & merge the most recent few PRs, but I don't have permissions yet.

bastibe commented 1 year ago

@jmay, Github listed you as "invite expired". I've sent you another one.

casch-at commented 9 months ago

I had and still have to resolve personal things, but I think I`m fit enough to contribute again. A big thanks to all the contributor for helping to improve org-journal. @bastibe also reached out around 2021 in person, but at that time a wasn't fit enough to continue, sorry for not being honest -- Does that mean I have passed the "I'm not a robot" test?

I think it's generally a good idea to never commit to master, and to only merge pull requests if at least a second person has accepted it (barring time-critical bug fixes etc.). I also think it's a generally good idea to not have too many fixed rules to follow and keep things informal and personal 😁.

The CI is running again 👍🏽 So no commits at all from now on to master "(barring time-critical bug fixes etc.)" etc. loophole :-D

What about time constraints? What if nobody is answering for N days?

bastibe commented 9 months ago

I'm glad to hear that you're feeling better, and I'm glad to have you back in action!

Nevertheless, always remember that we're doing all of this for fun only! Our personal health and wellbeing are way more important than this here project. Stay safe everybody.