Open Hour 2020-JUN-04
- Salt news and updates
- SEP status updates: SEP #22 – unsupported releases url (https://github.com/saltstack/salt-enhancement-proposals/pull/28) and SEP #18 – release label improvements (https://github.com/saltstack/salt-enhancement-proposals/pull/24)
- Working Group Highlight: Cloud Working Group with Nick Hughes
- RC status and updates
- Python 3 test coverage
- Open discussion and questions
- Salt Virtual User Groups resume June 24 and will happen 3-4 times per month. We’re aiming for a variety of topics and speakers from both the Core Team and our contributors. If anyone has questions about speaking or is interested in giving a talk, Cassandra can help schedule that.
- Communication channels: Slack, IRC, and the Google Group/Mailing List are the main communication It channels our community members use. We’ll share release news, SEP updates, “What’s Happening This Week?” posts, and Open Hour agendas on all of those channels, and post them on the Community Wiki.
- The Community is becoming a hub for community information. It’ll grow and evolve as we add more items to it.
Cassandra Faris and Sage Robins
- SEP #22 (unsupported releases url) is merged.
- SEP #18 – release label improvements
- We’d planned to close this SEP, but are reconfiguring and reworking it based on community feedback.
- There will be a new SEP that dives into deeper questions that the original labels SEP wasn’t meant to address. It will have a broader scope and will hopefully address community questions about the release cycle and the timing of PR and issue resolutions and merges. It will also include discussion on severity and other labels plus the use of release milestones.
Community Member Nick Hughes
- We hear a lot about Working Groups, but don’t always know what they’re doing. These highlights let them share their projects with the greater community and potentially find more members. Anyone is welcome to join a Working Group. The Working Group meeting schedule is on the Salt Community Events Calendar.
- The current Working Group focus is idem. Idem is one of the next generation open source platforms that was announced last fall. Cloud providers are the first foray into releasing idem plugins into the world.
- Idem Background information: Thomas Hatch came up with the Plugin-Oriented Programming (POP) paradigm. Idem was one of the applications released in POP. It’s similar to the stateful enforcement and execution module functionality that is in Salt today. It allows us to write plugins that are in separate repositories. They can be iterated at their own speed and contain the cloud functionality that we’d like.
- Cloud Working Group meets every month. Members don’t need extensive Cloud knowledge to join. The group is a place to learn as well as a way to contribute.
Sage Robins and Frode Gundersen
- The RC went out May 2 as planned. We announced it across the communication channels.
- The core team is testing the RC, finding issues, adding them to the Sodium project board, and asking people to label them. The person on triage alerts the team of critical issues. The team is currently working on several issues.
- Community members are concerned that some issues don’t have test coverage and haven’t been used by people running Python 3.
- We have a test coverage improvement opportunity. Currently, not everything has tests. Without tests, there’s no way to tell if an underlying item’s removal breaks functionality. One way to help is to get the RC, run it in your local environment, and run Salt under Python 3. The more people test the RC, the more things we can find that lack test cases and/or have bugs.
- For test help, reach out to Wayne or bring them to the Twitch Test Clinic streams.
Community and Core Team
- Closing PRs
- What’s the approach to handling the PR backlog now that we’re moving more quickly? The concern is PRs that have been waiting for a long time will be closed without being addressed.
- It’s frustrating for contributors when PRs sit for months without acknowledgement, then get closed due to abandonment.
- Contributors get a week’s notice asking them to rebase the PR against master and telling them the Core Team is available to help if needed. They get a week to respond before it’s closed. The PR doesn’t have to be resolved or rebased within a week. It just needs to be acknowledged by the contributor in order to stay open.
- Currently, there’s a lot of noise in the PR backlog making it hard to decide where to focus. We want to focus on the contributors who are active and prioritize their PRs. All PRs are valued, but resources to manage them are limited. PRs that have activity are prioritized over those that appear abandoned.
- In some cases, the PRs sit because the contributor doesn’t have capacity.
- Takeaway: Core Team to change the messaging on closing and closed PRs. Clarify that if the contributor acknowledges the PR, it won’t be closed. Also make sure contributors know we can reopen closed PRs at a more convenient time.
- Community Feedback
- Feedback is always welcome as we work to improve collaboration and the Salt project. We are a community working together and need feedback to help the project succeed.
- One of the main Community Manager duties is gathering feedback, prioritizing it, and working to address it. If there’s something you want to discuss, reach out to Cassandra.
- Contributors Abandoning PRs
- People sometimes abandon PRs because they don’t get a response.
- Within a few days of a PR being submitted, a Core Team member should look at and acknowledge it.
- The eventual goal is to acknowledge them within a business day and review them within a week.
- GitHub Notifications
- Default GitHub notifications are too noisy to effectively tell people which PRs to address in a day, which can cause PRs to go unacknowledged.
- GitHub notifications have new configuration and filtering options. Users can filter by repository and use “is lookups” and reasons to help manage PRs. Users can also share those notifications.