This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
馃挅 extending number of ansible-lint cores (maintainers) #815
Comments
@ssbarnea Thank you for raising this. @ssbarnea Are you happy for people to use this issue to track who maybe interested in being added to the project? Do you have any initial suggestions you'd be happy sharing? |
I would like to nominate https://github.com/albinvass as I worked with him on maintaining zuul-roles (ansible), he made few good contributions, including writing a custom rule for zuul project. If others want to involve more in shaping the future of ansible-lint too, now it would be a good moment to address their interest. |
I would be willing to take a maintainer role. But I already have a ton to do so I'm not entirely sure how active I would be able to be. :) |
This comment has been minimized.
This comment has been minimized.
@ssbarnea and @albinvass now both have commit on ansible-lint |
@gundalow Thanks for that! This move will help making the linter an actively maintained and evolving. Both of us have good experience working in distributed projects with very strict review and merge polices. I want to state that the invitation will remain open for others. We do want to see others interested in becoming core contributors to the project. In fact we do not need much help implementing new features, most useful help is to review open reviews and occasional proposals that could affect the behavior of the tool. |
I'd be happy to help out, I use ansible-lint personally and professionally and would love give back. |
@dpendolino feel free to start with contributing to
help wanted
. Not having privileges on GitHub shouldn't stop you from contributing... |
@dpendolino Welcome to the community, thank you for offering to help. For long winded reason, github.com/ansible only has permissions for read/write/owner. So for the moment I've given you GitHub is used to track work. We also use Thanks again, and please do shout out if there is anything we can do to help support you. |
@dpendolino FYI you'll need to accept the invite first (check your email inbox!) so that we'll be able to assign you to issues and reviews. |
Hi, I would like to help out too! As mentioned previously, I have working knowledge with python and am trying to build up on my ansible knowledge at the same time. Will like to contribute to this project since i have the time too. |
@webknjaz Accepted! |
@tohtohro great! Do you need any pointers? You could start with things under "help wanted" that include some refactoring requests, for example. Also, participating in reviews is a good place for help too. |
I am a huge ansible-lint fan and think it is one of the key tools that ansible users have. I would be happy to help out with triage or whatever else is needed. I am a fairly experienced python programmer as well. |
@nixfu perfect! There's some tasks related to the project maintainability (like getting rid of unittest.TestCase relics) and just bugs (that may need reproducers or confirming against master):
Choose whatever you care about and participate :) |
I'd be happy to jump in as a maintainer of ansible-lint. It's a very useful tool, and has helped me improve my playbooks. |
@nixfu and @benyanke I'm glad you find ansible-lint useful, thank you for your kind offer of help. If you accept your invite via https://github.com/ansible/ansible-lint/invitations then we can assign issues and PRs to you. Just let us know which you'd like to work on. In the future, we should be able to give you |
@tohtohro Same as above for you. Thank you :) |
I'd be more than happy to help with reviews. Please let me know how do I get involved. Thanks! |
raises hand Put me in, coach! I spend my days writing Ansible and Molecule tests - and half of my evenings, as well. |
@rafaelfolco @greg-hellings Welcome and thank you for your kind offer to help. Please accept the invite via https://github.com/ansible/ansible-lint/invitations then we can assign issues and PRs to you. Just let us know which you'd like to work on. In the future, we should be able to give you |
I would like to propose @geerlingguy and @greg-hellings as cores as I seen both as being being focused on Ansible QA and will a good eye to spot potential issues that could be caused by incoming changes. It also happens that both of them are redhatters, which should ease the vetting process. |
I'd be okay with it, though I can't promise any level of commitment. I can jump in in bursts here and there as I get time :) (as I'm sure we'd all say, ha!). |
@ssbarnea I am interested in helping out here. I did some analysis on lint tools last year and covered some of the "features" and have some ideas on direction. Let me know how I can help out. |
Watch the project, perform reviews and feel free to try making any PR. I would focus on simple changes for which we already have tickets. Also be sure you join the irc channels, they are a very good way to collaborate. Look at existing PRs that are not drafts, regardless if CI reports red, sometimes that red comes from a non-voting check. Look at them and comment, feel free to agree or disagree with anything you see there. In case it was not clear, merging any change requires one peer core review. This works fine for changes coming from outside as we managed to close all but it can prove more problematic if changes are proposed by am existing core, as there are less options available, especially if consensus is harder to reach. Still, even if you are not a core, you can review and explain why you support or not a particular change. Usually this should be enough in order to unblock PRs. |
@gundalow @awcrosby I would to propose transferring ansible-lint project from ansible github organization to ansible-community organization, like we did back in January with molecule. This will allow us to invite other collaborators to the project and make its maintenance easier. The only downside I see is that the github url will be bit longer, but I think that the benefits will be seen very quickly. Also the transfer does not break any URLs as github is very good at redirecting. |
Any update on this? We should also consider dropping those that did not had any activity in 6 months from the list of cores, so the list of potential reviewers would be decluttered. Obviously that their status could easily be restored if they return but it does make no sense to list them otherwise. |
Sorry for hi-jacking a little bit but from my ansible-lint user point of view, as long as it's maintained, finding ansible-lint in ansible-community instead of ansible doesn't make a lot of difference. So, if the only way to see it maintained is to move it, so be it. I mean, for instance, molecule is used even if it's in ansible-community/ Again, all that really matters is to have it maintained and not dead. |
@ssbarnea Thanks for inviting me. |
I am closing this to cleanup the backlog but keep in mind that the invitation to extend the list of maintainers will always be open. |
@ssbarnea how about converting this into a discussion? I think it belongs there + it could be pinned on that page. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Summary
I would like to propose extending the list of people with core rights (review + merge) on ansible-lint project.
Additional Information
Mainly the community maintenance was an expected measure when the project was adopted about 1.5 years ago. Since then, @webknjaz lead the project and lots of changes where made. Still, maintenance can easily become a burden and no project should rely on a single person, especially and that is mostly his personal time. It is much better to have a small group of people doing this.
Regarding how to achieve this goal, we could use a a layered approach. First we invite those interested to help to become collaborators with triage permissions. Likely those would need at least one or two contributions to the project in the last year before being considered collaborators.
This means that they would be able to edit labels, assign tickets, close/open tickets and PRs and perform reviews. Still, they would not be able to push/merge directly.
Once they prove to be reliable reviewers, we can elevate their permissions to allow merges.
Regarding merges we can also enable the "require 1 review for merge" option, so nobody would be able to merge stuff without having at least someone else approve his change. For me this is a no-brainer even for small projects, as on OpenStack we require at least two reviews, and reviewers need to be from different companies. Luckily we don't need such requirements here.
The 3rd level of access is the permission to create a release (tag), that is something where we should continue to rely on Ansible Galaxy decision, especially for major version changes.
The text was updated successfully, but these errors were encountered: