-
Notifications
You must be signed in to change notification settings - Fork 100
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 project maintenance #134
Comments
This is awesome, thank you! Huge proponent for CI/CD - you're preaching to the choir! Can you elaborate on what you have in mind? Here's a quick braindump for more info and context:
Thanks again for opening this ticket. I'm excited! |
@jorisroovers I will be back later with more details but for start you may explain me why #133 didn't trigger any build?! When I seen that I really got scared ;) |
I only "recently" (few months ago) moved from TravisCI to GH actions, I reckon this is just an oversight in the CI trigger. Can have a look later if you haven't in the meantime... |
This should catch issues before they are merged. Relates to #134
This should catch issues before they are merged. Relates to #134
This should catch issues before they are merged. Relates to #134
Moving discussion here from #133 in which @tbekolay and @sigmavirus24 suggested to moving gitlint under the Python Code Quality Authority project. @ssbarnea had suggested something similar in the OP, suggesting to move the project under the @pycontribs umbrella. While I understand neither of those are "official" python projects, I'm honestly flattered at the suggestion alone. Especially PyCQA which has some tools under its umbrella that I've been using for many years, are widely popular and have been inspirations for gitlint. For these reasons I'm leaning more towards PyCQA. Having said that, I want to make sure I take a bit of time to let this sink in a bit, read up on the details and better understand how it would ultimately impact gitlint and myself - obviously there's some personal attachment to gitlint after working on it for 5 years. I'm fairly sure that for gitlint it would be a good thing (probably more visibility, more contributors). |
So there's one myth that a lot of people seem to have that I'd like to dispell:
I don't think this is strictly true or has any evidence that it's happened for other projects. I don't think it ever happened for Flake8 and I don't know that other projects can say it's happened for them. That said, it is easier to empower contributors because teams have more granular permissions than I've seen on personal repositories so you could allow folks to triage issues and close them without pushing/merging code. Etc. That's a great way to get folks started, build trust, and help them grow into good maintainers (if you have the time and attention for it).
That sounds good to me. Take your time. I know it can be hard to divorce your identity from something you spent so much time on. It's hard to take something your proud of and make it a little less visibly tied to you |
@sigmavirus24 While there is no guarantee around "more contributors" part, I do for sure that flake8 is special case. AFAIK, that is the only PyCQA project that is not under github and instead if under gitlab (if i remember correctly for historical reasons as nobody bothered to move it). I am ready to bet that lack of extra contributors on flake8 has something to do with this. At least I am glad that @asottile does a good job maintaining it. My advice regarding organization: it is not so important as long is not another single person behind it. I seen projects moved multiple times between organizations without much fuss as github seems to be very good at redirects. What it matters is the message sent: this project has better survival chances as there are others that can takeover the burden if needed. |
@ssbarnea other examples on GitHub include baron, red baron, doc8, bandit, and pycodestyle. None have seen a magical increase in contributors since moving to the org |
I sent @jorisroovers an invite to pycontribs org, so we could perform the move if we wants. I think that @sigmavirus24 can do the same for PyCQA. |
It seems invites expire (based on recent experience on-boarding the python-modernize team), so I'd rather let Joris decide when I should send the invite |
A bunch of my own and my employer's projects are using |
Wait, Poetry has started supporting real python development? Interesting Based on your blast of PRs @l0b0 I'm guessing your first order of business would be to change the commit style guide for the project? |
@sigmavirus24 Yes, we're using Poetry for "real" Python development, see for example this repo. I know it might be a controversial subject, so I might bring it up sometime later if people are interested in the whys and hows. As for the commit style guide, I'm not sure what that is or why I should/would want to modify it? :) PS: Amazing work on PyCQA by the way! I use a bunch of those tools for my projects, and I'm a big fan of anything which automatically makes my job easier. |
Thanks @l0b0 for your interest and all the PRs, very much appreciated! Always fun to hear about who is using gitlint as well :-) Already merged a few PRs and commented on issues. FYI that it might take me a (long) while to get to everything. That's exactly what this thread is about :-) Please keep submitting PRs etc, if this works well for a while (few months) I'd definitely be willing to add you as a repo collaborator.
@sigmavirus24 is referring to the fact that in the PRs you submitted you've been following conventional commits style guide, which I haven't followed before. I don't really have a strong opinion on this for gitlint (vs. a large project with many commits and contributors all working in parallel, where I think this is quite useful). There's an argument to be made not to enforce it, so we can keep running gitlint running against itself without special config (enforcing Conventional Commit is a contrib rule and not enabled by default). Counter-argument is that it actually show-cases gitlint more if we use a custom configuration against itself 🤷♂️ Either way, you can use it, doesn't mean we need to enforce.
I use poetry myself for other projects, and I like it. I've considered this before for gitlint. However, I'm not an expert, have never used it to publish to pypi and not 100% clear on the overall implications. This probably requires a separate issue and more discussion. Other notes:
|
Can I throw another suggestion in the mix? I don't have any affiliation with https://github.com/jazzband, but it does seem to work well for the https://github.com/jazzband/pip-tools project. |
Jazzband also has lots of abandoned projects there last time I looked. |
@sigmavirus24 I think we may be barking at the wrong tree as @jorisroovers already stated he wants to avoid potential dilution of fame by moving under a community driven organization. I effectively stopped even trying goodies/tools that have a single maintainer as being too risky. Example ymyzk/tox-gh-actions#74 I guess many python developers do remember at least some of the ugly things that shaken the requests library at some point. I am more than happy to contribute back to projects that are open by nature. I have a saying in my language that with would relatively translate to once bitten, twice shy. |
I think you're conflating Kenneth's ego trips with Joris' pride here based on the rest of your comments. That doesn't feel fair to Joris. I might be forgetting part of this conversation though |
True, is not a fair comparison. The only intent was to highlight how bad it can go in some cases. Joris has deserves all our respect and I really loved his blogpost. |
Gitlint is a labor of love. I’m both attached to it and am proud of it, I believe that’s a good thing to have in a maintainer 😊 And yes, it’s nice to have my name clearly associated with it; I don’t think that’s a crime. If I ever get the feeling that I’m really dropping the ball or am ready to move on, I’ll speak up. I do think that day will eventually come, but I don’t know whether that’s months or years out. As I said last time, I’m happy to give co-maintainer access to this repo to folks after we’ve done a bit of trust building by collaborating. @sigmavirus24 has crossed that threshold for me after consistent involvement commenting on various issues for the last 2 years or so. So Ian let me know if you’re interested. I love open source and am a strong believer in how it’s a force for good. The last thing I want is give the impression I’m somehow above that or “not open in nature”. This doesn't mean we all have to agree on everything and that every decision needs to be made based of majority opinion or even consensus (case in point #162) - as long as the discussion is public, respectful, and constructive, it counts for me. Hope that makes sense. Thanks for continuing to care, means a lot! |
I can't promise I'll have more time than you have presently but I'm happy to help. I'm honored you trust me to add me here |
@jorisroovers I haven't seen this stated before, but I'd like to point out that having collaborators on repos hosted under personal user profiles has some technical limitations. If you want to retain power but get rid of those limitations, I suggest creating your own GitHub organization and moving the repo there. There's a lot of projects doing this — orgs have a lot more flexibility compared to individual user accounts. You could even call it |
Not sure if yet-another-org is the best, but I can see these orgs as potential matches:
|
Quick acknowledgement of your suggestions - thanks :)
This is still where my mind is at today. For the time being, I still prefer the project to remain under my personal account for the reasons outlined before. Appreciate your understanding! |
@jorisroovers Based on your call for help, I raised this ticket. I think we all could use a good git message linter and I am willing to help.
I had a good track of reviving maintenance on other projects and make them more of a hands-off.
Most of them are hosted under https://github.com/pycontribs/ -- an community effort aimed to help maintaining python projects, mainly by assuring that the projects do not depend on a single (human) point of failure.
The recipe is relatively simple but boring: fully automated CI/CD and bit of housekeeping. Once done most projects can self-sustain.
The text was updated successfully, but these errors were encountered: