Contributing to DLRS

DLRS joined the Salesforce Open Source Commons in August 2021. Now there are 30+ volunteers on the team both from Salesforce and the community. Andy Fawcett is still actively involved with the Dev team helping shape the roadmap and Architecture.

Team Structure

The DLRS volunteers are broken up into several teams:

Project Manager

• Run the Monthly meeting
• Maintain the structure for volunteering
• Maintain the list of active volunteers
• Coordinate the monthly Agenda with Team Leaders

Curent PM:

• Jim Bartek - @jimbtek

Support

• Answer questions in the DLRS Community
• Triage GitHub Issues

Team Leaders:

Documentation

• Maintain the GitHub Wiki
• Make it easier to understand DLRS

Team Leaders:

Release

• Streamline the release process with CumulusCI, Metecho and other tools

Team Leaders:

Dev

• Make changes to DLRS' core functionality
• Determine standards for contributing including formatting and other rules (PMD)

Team Leaders:

QE Testing

• Increase code coverage and edge case testing
• Ensure DLRS is compatible with the next version of Salesforce

Team Leaders:

UX (User Experience)

• Improve the usability of DLRS from installation to configuration

Team Leaders:

Meetings

Monthly DLRS meeting - 3rd Tuesday at 11am Eastern Time

• Get check-ins from each team
• Set goals for the Releases
• Meeting notes

Bi-Weekly Dev Office Hours - Every other Thursday at 11am Eastern Time

• Determine what dev tasks will be included in a Release
• Work through technical challenges
• Meeting notes

Project Management (Gettin stuff done!)

We will use the following methods to stay organized. This is subject to change as we get a handle on the large volunteer team structure.

GitHub Issues

Every task from the Community or from our team should end up as an Issue that can be tracked. If someone is going to work the Issue they should take ownership of it.

How to Triage Github Issues:

• Determine if the Issue is:
  • a User issue - label as Support, and possibly also UX or Documentation if there is obvious product confusion
    • Also you can remind the person of the DLRS Community as a better place for questions
  • a Bug - label as Dev Team, Bug, and Priority
  • a Feature Request - label as an Enhancement
• Once an Issue is Labeled, it is up to the members of that Team to decided if/when to start working on it by adding it to their Project Board, and placing a Release Milestone on it, and an owner. This should not be done by people outside the team.

If the issue is a duplicate, you can mark it as a Duplicate with the label, close it, and point it to a parent issue.

GitHub Labels

Every task should be labeled with the appropriate team above. It would be great if all team members can help triage and tag tasks, but after the backlog is sorted this will primarily be a Community Support team task. Issues should also be tagged with Labels like:

• bug
• enhancement
• priority

This will make it easier for the Teams to prioritizing when picking Issues to add to their Project board.

GitHub Milestones

Every task that the team has decided to work on, should get tagged with a release number. Examples are 2.15 or 2.16. The Milestones make it easy to document "What was achieved during Release 2.15"

GitHub Projects

Every task that the team has decided to work on, should also be added to that team's Project board. The Project board makes it easy to focus on just Work in Progress.