-
Notifications
You must be signed in to change notification settings - Fork 164
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
Comments
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. |
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.
Sure but it shifts the focus from having one maintainer to having a group of ppl responsible for progress.
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. |
Sure, it would be great.
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. |
Just want to address this once again. @Skycoder42 @Shatur are you fine in giving this repository to a rather democratic community? |
I'm fine with this, but I need to see someone to start working on it first to transfer it to an org. |
@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. |
Ofc I could just put a clone there. But moving makes sense if we want to keep the issues and such. |
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. |
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. |
With other people too, which is why I think that trust is important.
A lot of repositories assigned to their authors, it this a monarchy too? 😄 |
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. |
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. |
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.
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.
Someone could remove the repo or the org, for example. Or overwrite commit history. |
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. |
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 |
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: