Tue, Jun 18
Tue, Jun 11
I'll be moving this task to Done on the CS work board as RelEng is taking on CS responsabilities as it's being sunsetted.
Thu, Jun 6
Do we have a sense of what is causing these rechecks? @zeljkofilipin, have any insight into this. I know we've discussed it a little in the past.
I am in favor of leaving them as voting, especially if the primary driver to changing that is their flaky nature. Although I do understand the issue at hand, I'd like to work to find a different solution to the problem of flaky tests. Monitoring and acting upon flaky tests hasn't been a priority in the past, but we are moving to bring more focus to that in the near future.
Tue, Jun 4
Spoke with @Catrope and @MMiller_WMF re the ownership of this extension. We determined that this extension is outside the scope of the Growth team and would be better suited somewhere else. As such, this extension has returned to orphan status.
Hello @marcella, this extension came up as a Code Stewardship review request, but I've noticed that it is marked as being stewarded by the Editing team on developers/maintainers page. Just checking to see what the actual Code Stewardship status is before I dig any deeper.
Mon, Jun 3
May 24 2019
May 23 2019
May 19 2019
Apr 16 2019
Mar 29 2019
I think this is good starting point for some knowledge building around this. I think some questions around how to improve the Code Review process might make sense. For example:
Mar 18 2019
Tech debt identification and management is being done as part of the PEP refactoring work.
Mar 12 2019
When done, the extension review instructions should probably be updated.
Feb 27 2019
Another thought to capture... This process should probably result in a workflow that is as automated as possible. For example - initiated by the creation of a phab task that then auto creates other tasks from template with appropriate folks subscribed/assigned. In the end, minimizing the room for error in a manual set of steps on a wiki.
Feb 26 2019
Although the goal is to have all code that deploys to production go through this process, it may be necessary to have two branches in this process. One that is for "permanent" deployment to production, and one that is "conditional". For example, team needs to get new capabilities into the production environment in order to obtain timely user feedback, but the code is not fully compliant to Code Health, security, performance, etc... criteria. They may have a time-based condition to address the gaps or be removed from production.
Feb 20 2019
@EvanProdromou, that sounds like a good thing to pursue. Definitely something worth investigating. Let me poke Tyler/Dan to see the feasibility for using K8s for that today. I know that there's some work in this space that could be leveraged.
@Aklapper, this was basically a request for assistance with Chromium profiling. If you know any particular person and/or team that might have expertise with this, please let me know. That being said, I'm not sure if Piotr still needs help with this.
@pmiazga, is this something that you still need help with? If not, are there any learnings/findings about this topic that you're able to share?
Feb 15 2019
Feb 14 2019
@greg @Kunal, @Krinkle and I were chatting about moving this forward. Sounds like the next step is to have a discussion about what it would take to archive the data. Once we scope it out a bit we'll be in a better position to understand the effort involved and whether or not we need to get supplemental funding.
Feb 13 2019
In any case, and with the risk of repeating myself, the service is under a code stewardship request cause it does not have currently a maintainer. If we want to keep it around, we need first and foremost a maintainer.
@MarcoAurelio, we're going to move forward on undeploying this extension from production. I'll create a task shortly.
Feb 12 2019
Jan 24 2019
If I interpret this correctly, the reason we are looking to undeploy/sunset this extension is because it is no longer actively used for code review activities and we are looking to reduce the deployed code base in order to minimize complexity/failure points. It is however, used for historical review of past code changes. The desired outcome would then be to undeploy the extension whilst preserving access to past code review activities.
My key takeaway from this discuss is that although we could address the issues/shortcomings of this extension as it is today, there isn't much perceived value in doing so. As a result, it appears to make the most sense to move forward undeploying/sunsetting this extension.
Jan 16 2019
I was thinking about having a session about the broader Code Health topic on the unconference day. Perhaps we could discuss this in more depth during that session (if it happens :-)).
Dec 17 2018
Dec 13 2018
Dec 11 2018
Nov 27 2018
The post mortem process now includes a section on test/escape analysis.
Current unit test coverage has become part of the Code Health newsletter. Code coverage numbers will also be a key component of what is reported through the Code Health Metrics.
Progress to date:
- Slow going at first as this is a shared goal. Originally a Q1 goal, this has moved to a Q2 goal in order to allow CPT to get through some of its PEP planning.
- Meeting with CPT this week to plan next steps.
Progress to date:
@Catrope, we can certainly find another home for this extension if you think another team is a better fit. Out of curiosity, is this related at all to the change from Collaboration to Growth? I'm trying to get a sense of whether the wrong call was made when we first reviewed this extension for Code Stewardship or if things just changed since then.