The Secure Analyzer Frontend team supports the scanner/analyzer groups beneath the Secure sub-department.
|Neil McCorrison||Frontend Engineering Manager, Secure|
|Dheeraj Joshi||Senior Frontend Engineer, Secure|
|Fernando Arias||Senior Frontend Engineer, Secure|
|Jannik Lehmann||Frontend Engineer, Secure|
|Paul Gascou-Vaillancourt||Senior Frontend Engineer, Secure|
Given the number groups this team supports, we prefer to be aware of upcoming features as early as possible. During the time leading up to implementation we will strive to:
We seek to have issues ready for backlog refinement activities by the 1st of each month, therefore allowing enough time for us to determine the appropriate implementation plan and finalize relative sizing of the candidate issues in a given release.
Look to see if issue you are working on has existing test coverage. These are the tests likely to fail
If you are working around code that contains a selector like
data-qa-selector="<name>", then there is likely to be an existing E2E test. Tests can be found by searching our E2E tests in Secure.
All Deliverable issues should be marked
On Track at the beginning of a milestone. If there is concern with doing so, then we should discuss why.
Issues that have not gone into review by the 8th may not have enough time to get merged. These should be considered Needs Attention or At Risk depending on their complexity and other factors.
Raising risk early is important. The more time we have, the more options we have. Follow these steps when raising or downgrading risk:
On Track- there is no indication the work won't get merged by the 15th.
Needs Attention- the issue is blocked or has other factors that need to be discussed.
At Risk- the issue is in jeopardy of missing the merge cutoff of the 15th.
Note that an issue probably shouldn't go directly from On Track to At Risk. Consider a progression:
On Track -> Needs Attention -> At Risk.
Our team monitors LCP (Largest Contentful Paint) to ensure performance is below our target (currently 2500ms).