Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Future of this project? #90

Open
ManuelSchneid3r opened this issue Jul 2, 2023 · 17 comments
Open

Future of this project? #90

ManuelSchneid3r opened this issue Jul 2, 2023 · 17 comments

Comments

@ManuelSchneid3r
Copy link

This project is apparently dead. At least none of my issues over the last months (#89, #87, #80, #77, #63) got handled. Also commit date of HEAD^3 is one year ago.

I dont want to just blame smdy, but rather suggest some solutions. I think not a single person (who can have no time due to real life) should maintain this repository. I think the best solution would be if we make an orgnization where multiple maintainers can work on multiple projects.

Iirc i proposed this already a long time ago. Iirc I heard the argument that this makes sense only if we have mulitple projects. Now i have the urge to write a QDesktopNotification abstraction coming up and I think this approach is really necessary.

@Shatur
Copy link
Collaborator

Shatur commented Jul 2, 2023

This project is apparently dead. At least none of my issues over the last months (#89, #87, #80, #77, #63) got handled.

No one obligated to resolve opened issues. The original author is not active, yes. But if you open a PR - I will review it and merge it ASAP.

If you create an organization it's not resolve your issues. This is not how it works.
I became co-maintainer because I contributed to the project. If you want to participate - start addressing issues.

@ManuelSchneid3r
Copy link
Author

No one obligated to resolve opened issues. The original author is not active, yes. But if you open a PR - I will review it and merge it ASAP.

Correct, but what I strive for is a community/democratic appoach. It makes sense to have a maintainer for each platform and peer reviewing besides yours is nice to have.

If you create an organization it's not resolve your issues. This is not how it works.

Sure but it shifts the focus from having one maintainer to having a group of ppl responsible for progress.

I became co-maintainer because I contributed to the project. If you want to participate - start addressing issues.

I dont necessarily want to become part of it. I want you to be not the only one part of it. I believe that in an organization ppl would rather often send PRs and probably want to join the maintainers and reviewers.

@Shatur
Copy link
Collaborator

Shatur commented Jul 2, 2023

It makes sense to have a maintainer for each platform and peer reviewing besides yours is nice to have.

Sure, it would be great.

I dont necessarily want to become part of it. I want you to be not the only one part of it.

I would be happy to see more co-maintainers. But so far no one is interested. I doubt that inside the organization there will be more. When I submit a PR I don't care if it's an organization or a single-person project. I care only about merge and review.
But if someone will start contributing and ask us to create an organization - I would be happy to see the transition. It's a matter of trust.

@ManuelSchneid3r
Copy link
Author

Just want to address this once again. @Skycoder42 @Shatur are you fine in giving this repository to a rather democratic community?

@Shatur
Copy link
Collaborator

Shatur commented May 25, 2024

I'm fine with this, but I need to see someone to start working on it first to transfer it to an org.

@ManuelSchneid3r
Copy link
Author

ManuelSchneid3r commented May 25, 2024

@Cuperino @ManuelSchneid3r @Shatur. Cute community right? It is rather about using the Github features to have things like automated merging with reviews. Its not that you (or @Skycoder42) give it away or something. Ofc I'd make you admins of the community, because you are part of it.

@ManuelSchneid3r
Copy link
Author

Ofc I could just put a clone there. But moving makes sense if we want to keep the issues and such.

@Shatur
Copy link
Collaborator

Shatur commented May 25, 2024

What I meant is I need to see people started contributing first. It will be strange to just move the repo to a community because someone who is not even a contributor showed up and asked to move it :) That's not how it works in open source. Usually someone starts working on a project to gain trust first.

@ManuelSchneid3r
Copy link
Author

You dont need trust it if you are part of it. But, okay ill put a clone there. I am not really keen on moving it but rather the democratic authority, because monarchy is not open source spirit either.

@Shatur
Copy link
Collaborator

Shatur commented May 25, 2024

You dont need trust it if you are part of it

With other people too, which is why I think that trust is important.

because monarchy is not open source spirit either

A lot of repositories assigned to their authors, it this a monarchy too? 😄
Everyone is free to fork or open PRs.

@Cuperino
Copy link
Contributor

Democracy is a family of political systems for balancing power. Open source licenses and GitHub as a platform give everyone the power to fork and to do their own checks on power. That puts this ecosystem closer to a functioning anarchy, like N. Chomsky describes, where everyone does their thing and is free to associate and collaborate as they need. Given this framework, instead of focusing on political labels, which can create bias due to difference of ideologies, we should continue to ask ourselves: What's good for the project?

Having trust and a lack of it are both a quintessential part of free software and open source software. You have to trust people will follow the terms of the licenses and even accept when somebody follows the letter of the license but not the spirit it was written in. You have to distrust people or, to be specific, be skeptical when it comes to their contributions because a few people will attempt to do bad things, regardless of their intentions. Bug triaging and tools for CI help us address this need for distrust, which we could also call safekeeping. Maintainers such as Shatur attend to that need. Giving control away in the name of democracy is disregarding the need to be skeptical and adds to the project's workload.

So far Shatur has been doing a good job of evaluating and helping address PRs. I may have needed to reach out to them with a tag when CI had broken, but when I did Shatur was there to respond. If someday everyone stopped responding I would continue to work from my fork and that or any other fork could become the new main project.

What I'm trying to say is free software and open source projects have a need for both trust and skepticism. So far those needs are being attended. An argument could be made that if something were to happen to Shatur or Skycoder42, we wouldn't know where to upstream our contributions, but moving the project to a GitHub organization alone wouldn't solve that because in the end it boils down to trusting people and it's better to have more people you can trust.

@ManuelSchneid3r
Copy link
Author

Democracy is a family of political systems …

Its not just politcal labels. Sure it is an analogy but it is a good one because the core thing I want to address is the form of government. Its about authority. Having a single person deciding on everything that happens - approvals, rejections, desing decisions… - is not an anarchy. The analogy to a functioning anarchy would be to have QHotkey-ng, QHotkey2 etc. Each individual governing itself. Nobody (of the clients) wants this.

I am not talking about the inter project relationships, but the intra project relationships. Since development essentially stalled I just wanted to suggest to change the intra space. Having an open minded (fluid) team rather than a single person (and hoping for the "good dictator") is an improvement in every aspect. Perceived openess, likelyhood that somebody joins, more manpower, peer reviewing, latency for fixes or issue responses, less pressure on maintainers … I think I dont have to elaborate on the benefits. I'd go even further and invite users of the library to join the team.

Considering the bad. What could go wrong? Even if a bad auto merged commit found its way into the library we could always revert it.

But sure the authority has to decide on the change of the authority. If this is not what you have in mind I am okay with that.

This sounds all way to serious and grim. I just wanted to answer the last post and clearify what I meant with my (too limited for this kind of topic) foreign speaker language skills. :D All good.

@Shatur
Copy link
Collaborator

Shatur commented May 25, 2024

Since development essentially stalled I just wanted to suggest to change the intra space

We aren't bottlenecked by reviews. We just need more contributors. It doesn't matter if it's an organization or a person's project.

Having an open minded (fluid) team rather than a single person (and hoping for the "good dictator") is an improvement in every aspect

It's good, but as I said, you need to start contributing first to gain some trust. You can't jump into a project and just ask the author to share the write access with you, that's not how it works.

What could go wrong?

Someone could remove the repo or the org, for example. Or overwrite commit history.

@Cuperino
Copy link
Contributor

What could go wrong?

A codebase like this one could also be used to implement a key-logger. That's a big security risk to be auto-merging contributions.

@ManuelSchneid3r
Copy link
Author

Fortunately github allows fine grained permissions. Ofc "super user" permissions should be only for a small circle of trusted maintainers. Actually we would not have to give write access at all if there were just a bunch of reviewers with approval permission, which will lead to the auto merges I was talking of. In that case keyloggers would not be merged ofc. Again I have to stress that I am jot trying to convince anyone. Just some thoughts

@Shatur
Copy link
Collaborator

Shatur commented May 26, 2024

No one is saying that it's bad to have multiple maintainers or an org. We just saying that it's not a good idea to share write permissions with people who you can't trust because they aren't contributors.

@Skycoder42
Copy link
Owner

Giving my two cents: @Shatur has done a very good job taking care of this project. I will trust them with whatever decision they make.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants