-
Notifications
You must be signed in to change notification settings - Fork 238
DLRS Monthly Meeting
-
Cori to share team email addresses and roles with Jim
-
Jim to create new Team Based Issue tags
-
Everyone to help Tag the open 189 Issues
-
Dev / Release team to review the CCI trailhead
-
Contributing to DLRS wiki page: https://github.com/SFDO-Community/declarative-lookup-rollup-summaries/wiki/Contributing-to-DLRS
-
What does an Issue need to be “Ready”?
-
How do we handle “Done” from the Dev team?
-
2.15 Release strategy ** https://github.com/SFDO-Community/declarative-lookup-rollup-summaries/issues?q=milestone%3A2.15+
-
Pick Team Leaders
-
Team Updates
-
(From Cori) What is the team's Definition of Done strategy? Ie. making sure all the things are done before the package is updated on the listing/MetaDeploy page.
-
Testing
-
Doc updates
-
Release Notes
-
Public announcements
- Pick Team Leaders who will PM their team’s project board and give team update monthly
- Fill projects with Issues and add Milestones to all Project board Issues (2.15 OCT or 2.16 JAN)
- Please fill out the Metecho training Doodle in Slack
- Next Dev mtg: ** What does an Issue need to be ready for Dev? ** What should happen when an Issue is “complete” from Dev and needs to go to QE and Release? ** Documentation plan for announcing new releases with OSC/SFDC help
- Who is Triaging GitHub Issues? JL & DD are typically moderating the Community, not GitHub
- How do we standardize closing an Issue that is really user support, and point them to the Community?
- Do we prevent anyone from creating an Issue and limit it to contributors only?
- Continuous Integration setup done
- Code Reformatting this week
- Metecho Training beginning Oct
- Dev Office Hours September 16th
-
CR recorded a video for the Documentation project that will be participating in the upcoming Community Sprint.
-
We have two projects we are working on ** (1) writing a setup and configuration guide for users ** (2) the cookbook that we're going to start on at the Sprint
-
We’re going to punt documentation of new releases for now, since we don’t have a basic guide that can be updated with new features yet.
-
The current Doc team doesn’t have the capacity to handle release notes or other more technical documentation. We are going to focus on the user side of things.
-
With the addition of BC and BF to the team, there is the possibility of making How-To videos for DLRS once the basic documentation is in place.
- Catching up to get started
- DLRS Winter '22 Testing
- Define Handoffs from Dev to QE to Release
- Extending the Test Suite