Additional project maintainers?

[rhansen]

Hi @rvaiya, thank you for a great project! I've noticed the backlog of pull requests is growing, so I wonder if it's time to invite additional maintainers to help review, merge, and make releases. I created https://github.com/keyd-project and invited you to make this easier.

If anyone reading this is interested in being a maintainer, please speak up.

[rhansen]

I created https://github.com/keyd-project/keyd-fork as a temporary friendly fork. I will work on merging some of the pull requests into that fork, starting with the easy changes (e.g., documentation fixes). I'll use that fork as the Debian package's upstream. I plan on inviting the maintainers of other downstream packages to help maintain that fork (cc @jirutka for Alpine Linux, @ainola and @Antiz96 for Arch Linux, @alternateved for Fedora, @bubbleguuum for openSUSE, TODO more?).

If you (@rvaiya) are amenable to adding me as a maintainer of this project, I would like to consolidate this project with that fork by doing the following:

1. Transfer this repo to the keyd-project organization. The project URL will change from https://github.com/rvaiya/keyd to https://github.com/keyd-project/keyd, but GitHub will automatically redirect https://github.com/rvaiya/keyd (including issue and pull request links) to https://github.com/keyd-project/keyd.

2. For each pull request I merged into https://github.com/keyd-project/keyd-fork (in merge order), sync the PR with the fork repo and merge:

   gh pr checkout $pr_id
   git reset --hard $sha1_of_corresponding_commit_in_fork_repo
   git push -f
   git checkout master
   git reset --hard $sha1_of_merge_commit_in_fork_repo
   git push

3. Archive the fork repo.

[ainola]

I'll give some time for @rvaiya to respond - but we'll keep our eye on this :). Thanks!

[rvaiya]

I do not see the need for a fork. You are free to maintain one, but please make it clear it has no connection to the official project. I am currently working my way through the backlog of issues.

[rhansen]

I have no desire to maintain a fork long term. The idea was to recruit members of the community to help go through the pull requests so that you didn't have to. All you would need to do is double check the work and reintegrate back into this project once you had spare time to work on the project again.

The number of users is starting to grow significantly. Because of that, I would very much like to see more than one active maintainer so that issues and pull requests are addressed in a timely manner, and to increase the project's bus factor. Please consider adding additional maintainers.

[rvaiya]

All you would need to do is double check the work and reintegrate back into this project once you had spare time to work on the project again.

It is not clear how this differs from me manually reviewing pull requests and merging them. I have already skimmed a number of pull requests and decided not to merge them for various reasons, but haven't closed them until I have had a chance to comment as a matter of etiquette. Other non trivial changes merit testing, which I have not had time to do.

Because of that, I would very much like to see more than one active maintainer so that issues and pull requests can be addressed in a timely manner

keyd takes a conservative approach and is focused more on robustness and good design than new features. Most PRs (especially those containing implicit feature requests) are not a priority, and the few which are actually bugs are merged relatively quickly.

and to increase the project's bus factor.

I am not dead yet and don't live in a sprawling urban environment, so this seems a bit premature ;).

[rhansen]

keyd takes a conservative approach and is focused more on robustness and good design than new features.

I'm not suggesting that you sacrifice this approach—you would of course want to pick maintainers that share your vision for how keyd should evolve. But 5 months is a long time for a downstream package maintainer to wait before proposed build/infrastructure improvements are looked at. Not that you should feel obligated to react instantly to every demand by the user community—just that it would be beneficial to the community to have more people around to react to pull requests.

[rvaiya]

You would of course want to pick maintainers that share your vision for how keyd should evolve

This does not require a fork. I am capable of making that decision independently and have already accepted patches from numerous contributors.

But 5 months is a long time for a downstream package maintainer to wait before proposed build/infrastructure improvements are looked at.

I assume you are referring to your autotools patch, which appears to form the foundation of your fork. I am not interested in adding autotools as a dependency to the build system, nor would I endorse any maintainer who wanted to do this. You also appear to support an independent C++ rewrite, which is another thing I have little interest in and does not advance the goals of the project.

I cannot stop you from maintaining a hostile fork, but I would appreciate it if you could vacate use of the keyd-project github namespace, which you appear to have unilaterally registered without my consent.

[rhansen]

This does not require a fork.

Agreed. But what does warrant forking is maintainers that are MIA when PRs are accumulating (I'm guilty of this myself). I have tried to make it clear that the fork was only meant to be temporary, to help pick up the slack until you returned to the project. No hostility was or is intended, only a desire to help other keyd users (and by extension, you).

I am not interested in adding autotools as a dependency to the build system, nor would I endorse any maintainer who wanted to do this.

Handwritten Makefiles like yours have numerous little problems, which is why I opened the PR to begin with. Is there an alternative you would prefer? I'm flexible, but I would prefer a conversation about this over silent dismissal of autotools.

You also appear to support an independent C++ rewrite, which is another thing I have little interest in

Expressing an interest in someone else doing the work is not the same as supporting it (not with how I define "support", anyway). I won't support it for this project unless you do. If someone wants to fork keyd and convert it to C++, I would follow it with interest but probably not invest any of my own energy into it, at least not until it showed promise.

and does not advance the goals of the project.

Neither does ignoring or dismissing people who are trying to help you. If this is just a pet project to you, that's OK—you don't owe anyone anything, and you should feel free to ignore me or anyone else. But if you do care about others using your project, alienating a downstream package maintainer is not the best move.

I cannot stop you from maintaining a hostile fork

Like I said before, I'm not interested in maintaining a hostile or otherwise long-term fork. (If a critical mass of other developers decide to fork and I trust the potential, I might volunteer to help out. But that's a lot of ifs.)

I would appreciate it if you could vacate use of the keyd-project github namespace

Do you want keyd-project? If not, I'll just delete it. If you do, I'll remove myself once you accept the owner invite. (I invited you as an owner when I created it, and I re-sent the invite when it expired. It's still waiting there for you to accept.) I'm not going to remove myself before you accept the invite because I don't know if the organization can be easily reclaimed once the final owner leaves. You can remove me after you accept the invite, or I can remove myself once I see that you have accepted.

which you appear to have unilaterally registered without my consent.

Again, just trying to be helpful. It's your organization—always has been—if you want it. I'm not trying to "steal" anything from you. And it's not as if its creation can't be easily undone.

[rvaiya]

Agreed. But what does warrant forking is maintainers that are MIA when PRs are accumulating

The fact that you do not like the release cadence is not an indication that anyone is 'MIA'.

I have tried to make it clear that the fork was only meant to be temporary. [...] No hostility was or is intended, only a desire to help other keyd users (and by extension, you).

Then please delete it.

Handwritten Makefiles like yours have numerous little problems, which is why I opened the PR to begin with. Is there an alternative you would prefer? I'm flexible, but I would prefer a conversation about this over silent dismissal of autotools.

Autotools is bloated and introduces more problems than it solves, but I am not inclined to have a technical debate about the issue here.

Neither does ignoring or dismissing people who are trying to help you.

I do not need this kind of help.

If this is just a pet project to you, that's OK—you don't owe anyone anything, and you should feel free to ignore me or anyone else.

This is needlessly incendiary, and rather petty.

But if you do care about others using your project, alienating a downstream package maintainer is not the best move.

Alienating the main developer by forking the project and trying to arrogate maintainership to yourself to advance the interest of your patch is also 'not the best move'.

Like I said before, I'm not interested in maintaining a hostile or otherwise long-term fork. (If a critical mass of other developers decide to fork and I trust the potential, I might volunteer to help out. But that's a lot of ifs.)

Everything you have done thus far is an indication to the contrary.

Again, just trying to be helpful. It's your organization—always has been—if you want it.
[...]
You can remove me after you accept the invite, or I can remove myself once I see that you have accepted.

This is not true, you have maintained administrative control over the organization. I do not have the power to delete it.

I'm not trying to "steal" anything from you.

These are your words, not mine.

Since you claim to be willing to delete the organization, I would like to unambiguously reiterate my earlier request that you do this.

I am locking this thread since it is no longer a productive use of time. I have already stated my position clearly.