Skip to content

Dev Office Hours

Jump to bottom Edit New page
andyjb edited this page Mar 3, 2022 · 15 revisions

Notes and actions from the fortnightly dev office hours call:

(10) 17th FEBRUARY 2022 Points discussed:

  • Who should merge pull requests? -> Agreement that we should have a group set up for a subset of users to have the merge privilege assigned. AB to co-ordinate.
  • TDTM is progressing well, potential to split into 2 parts whereby one could be released earlier, but strong preference currently for delivering all at once. RS to demo once in a suitable state.
  • MT raised a question about customers volunteering for early/beta testing. Will validate if there's a process with JB.
  • Setup of LDV org still on the table, org can be sourced easily, we need data and then a build process change. AB to co-ordinate data gathering, DR is fully aware of the options available re: build & deployment.

(8) 20th JANUARY 2022 Attendees: RS,AF,CSK,DR,MK,MT,CO

Points discussed:

  • Metecho would work for QA. Point-and-click, for admins, would replace VSCode / CLI. Populates scratch org with tool + sample data
  • Metecho instructions (Riley): We can use metecho as it stands now to test the current beta releases without needing to update the github repo. As long as you have read access to the open source commons project (If you dont contact Cori) and you will see DLRS after logging in with your github account here: https://metecho.herokuapp.com After selecting "DLRS" you currently need to create an Epic for each branch, to do so select "Create an Epic" and choose "Use existing GitHub branch", select the respective branch from the dropdown and name the Epic. There can only be one Epic per branch so if the branch doesnt show up then look at the existing Epics. The future goal is to have an Epic created for each release and a task for each feature in the release, however this will require the dev team to parent future releases differently. Once you open the newly created Epic then you can select "Create Scratch Org" which could take as long 15 minutes.
  • Metecho resources in dlrs-community-general Slack
  • Plan to move to Lightning Web Components, but can cause technical issues, since product was built on Visualforce

Agenda

  • Flow of stories through testing, UX review now under way
  • Code review tasks still to be done
  • CDC starter now available if anyone wants to investigate (I am happy to go through it with you) - I will also write up the details of the discussion I had with AF.
  • Metecho vs CLI?

(7) 6th JANUARY ** No attendees**

Points raised:

  • Testing: we’ve handed over the three Dev Done items for testing, keep an eye out for feedback from those
  • Code review: SC's PR has been reviewed and I believe the actions implemented so we need a final pass to confirm those changes (
  • Code review: the other two PRs are available for review, but may well change as a result of test/UX feedback. However, if anyone wishes to take a first pass beforehand, please feel free, just note in here so that we don’t duplicate efforts
  • Backlog: there are still items to pick up from the backlog. Feel free to allocate yourself to one and take it on. As mentioned before, the CDC one is more of a spike than a story, it will almost certainly generate further tasks, but is ideal for multiple people to get on to explore the possibilities
  • TDTM item: Moved that to In Progress as it was confirmed in the team call that meetings have been had, do manipulate it back if you feel that’s incorrect
  • Time/format of call: as ever, if Slack Huddle or the call time isn’t working, do shout. We can reassess when and how we do it to work for as many people as possible

(6) 9th DECEMBER Attendees: TD, MM, AF, AB

Points discussed:

  • TD has raised PR 1081 for the conversion of issue 803 into the new repo, requires code review & testing
  • Noticed some tooling changes locally, didn't commit but we'll ask DR & SK what the best approach is there
  • Also discussed Apex code standards (JS Lint equivalent) - do we have anything automated/do we have a standard?

(5) 25th NOVEMBER Attendees: MH, MM, RS, AB

Points discussed:

  • RS confirmed that whilst busy currently, hoping to pick up the NPSP TDTM work in early December

  • No other significant topics to be raised this time.

(4) 11th NOVEMBER Attendees: AF, SK, DR, RS, MT, VM-H, BF, AB

Points discussed:

  • AB intended to demo the functionality in the new creation wizard PR, SFDX issues, will create a video instead.

  • It was suggested that it could be possible to incorporate some feedback from the UX survey into the same PR (e.g. revising some technical field labels)

  • Potential future spike for LWC conversion (Doug Ayers' Mass Action Scheduler LWC tool looks to have worked out how to use the Metadata API with LWC) - AF to provide link

  • Ask JB to record next monthly call as AF unable to join due to customer commitments

  • Catch up with SC re: progress on Metadata PR

  • Later update: PR ready for review

  • 2.15 release status review:

    • all done from our side, beta package is ready
    • smoke testing needs to be done - Cori has asked
    • once confirmed, this will be the proper release
    • will now use the MetaDeploy functionality, maybe need a parallel option in the readme for the install link

  • SK needing access to an org to pull down data for setting up test data

  • AF will help out with API upgrade to inform where these changes are, let’s go for 53?

  • DX project enforcing API 48 at the moment

  • AF/DR to investigate if there’s a GUI-based SOQL generator

  • AF: performance is as much about education understanding whether the tool is being used correctly in the first place (i.e. does it have to be real time every time, or scheduled weekly) as actual performance issues

  • AF: for comment about tests needing to be written, could link community information into the UI

  • SK/AF: can we investigate if there’s some way of making DLRS and NPSP work nicely together, or even add the DLRS into the trigger handler? - TDTM (Table Driven Trigger Management)

    • set rollup to dev mode, allows you to not deploy a trigger, but need to call API, so could call from TDTM plug in

  • AF: clone seems like a quick win, wizard for a pilot, welcome page one as well

  • We are in a position now to set up some processes around the backlog

Actions:

  • AF to provide links for the Mass Action Scheduler
  • AB to provide video of new creation wizard in action
  • AB to instigate backlog maintenance processes
  • Team to carry on pushing items through the project for 2.16

(3) 14th OCTOBER Attendees: SK, AF, SD, BF, P, AB

Points discussed:

  • Outstanding PRs have been reviewed by AF, two are good to progress, but will need to be brought into the new format, conflicts resolved etc. before merge. Those items have been added to the project backlog.

  • Definitions of Done and Ready were discussed, but it was felt that populating the backlog was more important for now. Once this is done, we can create a draft DoD detailing what the tooling already enforces and collaborate as a team upon that, and the DoR. Any DoR though might impact the existing issues log and invalidate them, so some leeway may need to be given where the issues already existed.

  • The issues marked with Performance were reviewed, and selected items were brought formally into the dev project board.

Actions:

Team to pick up items and start working on them!

(2) 30th SEPTEMBER Attendees: SF, DR, AF, RS, SC, P, AB

Points discussed:

  • The outstanding PRs were discussed, as they need to be merged as a pre-requisite to any upcoming development work; either if a task is to be worked on from the dev project (so that it can be worked on with the standardised formatting) or if Winter 22 testing reveals an issue which needs fixing.

  • Once the two PRs are merged, beta package generation will then be done for testing purposes.

  • The dev backlog, or its absence at the moment, was discussed. There were questions as to how the items will flow from being on the issues board, perhaps with a dev team tag, to being in the dev project's Kanban board.

  • A further query was asked about the strategy for the content/theme of a release is decided. It was fully understood that any Winter 22 errors would need a dedicated 2.15 release for fixes, but that the next release after that is earmarked currently to be for performance, and what had driven that decision, and if that should affect what the team prioritise off the backlog when it emerges.

  • The discussion around performance led to a further query about how any potential performance improvements in the Performance release could be measured i.e. benchmarking and analysing current performance in order to be able to a) discover bottlenecks and b) be confident that subsequent changes have improved things.

  • AF presented an architectural walk through of DLRS, covering the major UI features and how the various available options change the flow through the code, which was well received by all.

Actions:

  • DR to facilitate the merging of the two outstanding PRs from SK - this is now done

  • SK to create beta package for Winter 22 testing - this is now done

  • AB to confirm with JB about the intended flow of items from the issues board to the dev team backlog, and then prioritisation with regard to release theme

  • DR to investigate with CO'B about the feasibility/precedents for LDV orgs in these projects in order to aid performance testing

  • AF to action the outstanding multicurrency PR so that the PR is closed but the branch is retained.

(1) 16th SEPTEMBER Attendees: SK, DR, AF, P, RB, RD, AB

Points discussed:

  • SK asked about the feasibility of code reformatting with regard to establishing standards for ongoing work, and if there were any objections to doing so, with regard to items such as potential confusion as to the identity of the original developer if that produces a large commit with SK’s name against it. There were no objections to this taking place in the immediate future.

  • SK referred to the number of open issues and the process for triage, replication and therefore categorisation. AF highlighted the issue reporting template which is structured to guide users toward the community if further investigation is required, and this should continue. DR suggested that some members of the team from non-dev roles could be appointed as support managers to triage issues to ensure that only genuine bugs reach devs/the actual backlog. It was felt that there was no precedent for subscriber access in such projects, and doubts as to whether it would be a reasonable avenue to pursue.

  • AB asked about the need for increased unit testing. AF described the current test landscape; whereas there are certainly tweaks that could be done to unit testing, the higher priority area is system & regression testing. DR described the regression org architecture used by NPSP. It was decided that a suite of Robot tests would be beneficial to the project. This would require some initial engineering setup, but the creation of scripts/sentences could be a team-wide activity.

  • The description of the unit test architecture led to a question from SK about the possibility of providing migration of SObject-based DLRS config to custom metadata format. AF recommended that this be added to the backlog, and mentioned that others active in the open source ecosystem were also looking at this.

  • DR suggested whether a Metecho introduction would be useful for the team, and it was felt that it would. SK also suggested addition of Metecho documentation.

  • Other ideas raised in the same conversation were a meta deploy installer, and the additional functionality into the health checker, although nothing was formally suggested for the backlog at this moment.

  • AB and SK asked about the process for currently open PRs, given that a number of the team are still getting to grips with the code base. AF took an action to have a pass through the PRs to provide direction and commentary for the team. There are some older PRs, and a number of them around multi currency adoption, of which it was felt some would need archiving. AF and DR agreed to clean up the repo with regard to these older PRs and appropriate archiving activities.

  • AF suggested whether an architecture overview would be useful for the team, and it was felt that it would. It was decided that this would be done in the September 30th session, with a proposed structure of a ~20 minute walk through followed by Q&A.

  • TD raised a question about organisation/prioritisation of the backlog, and how work would be allocated going forwards. It was discussed that this was not yet formalised, and that we would consult Jim Bartek for ideas and proposals.

Actions:

  • SK to implement consistent code formatting in the repo and to provide tooling to ensure this standard is maintained

  • AF to review open PRs to provide guidance and commentary for the team

  • AF to prepare architecture walk through for the next session (September 30th)

Add a custom footer
Add a custom sidebar
Clone this wiki locally