This has work has been rolled into the Data^3 project.
After some discussion, the Release Engineering and Quality and Test Engineering teams have decided to make QTE the "Product Owners" of BetaCluster. This decision comes as part of a larger testing infrastructure effort. The details of what this means and how we will proceed will come out over the course of the coming weeks. In the meantime, this task will be marked as Resolved as the primary objective of this task was to address the lack of "Code Stewardship" or more aptly "Product Ownership".
@Aklapper I like the prospect of doing something like this. There is a need to differentiating between the two primary task sub-types (bugs and features), and to do so in a consistent way across the projects as it makes reporting and analysis much easier. The QTE team has collected the aforementioned forms that we are aware of to better understand the current differences that may exist and the reasons behind them.
Oct 7 2020
I think the points/concerns brought up by @Jpita are quite valid. These are some of the experiences that we've had across a number of teams that we've worked with. That being said, there are a lot of separate problems that we need to address that will need to be done in parallel.
Sep 29 2020
@Aklapper this is a duplicate of T187487 in my opinion. There may be different/additional assertions being made, but those could be rolled into the other task. T187487 was moved to "Blocked" as it's fate was somewhat connected to the future of Flow if I recall correctly. Will need to revisit that discussion to see if any progress has been made.
Aug 5 2020
Sorry, being out of the office and changing my IRC usage (missing channels :-/) I didn't see this. The contract termination date is June 30th 2021.
Jul 1 2020
Approved on my end.
Jun 3 2020
May 12 2020
@Etonkovidova, we've (Performance team) started using Kobiton for native mobile testing, there's an overview on their experience next week during the EngProd summit. In addition, I talked to @zeljkofilipin and @ABorbaWMF about taking a peek at Kobiton, but I don't think it's bubbled to the top of the list yet :-) Both of these topics are probably good sub-topics to the broader compatibility testing task force we're looking to spin up.
should we discuss this on a meeting or should I ask on the mailing list?
May 6 2020
This should probably be forwarded to the On-boarding taskforce that was launched by Grant (CTO). Originally this was lead by Joel, but as he's no longer at the Foundation, I'm not sure who to pull in.
I think we can close this. We've got Code Health Office Hours and Quality and Test Engineering Office hours monthly. I think between the two of these, we satisfy the intent of this task.
I think this is something that is largely the responsibility of QTE. That being said, what was surfaced during the meeting is something that we need to take into account as we drive changes/improvements in testing. I'm good with either closing this, or assigning it to me until we feel like the feedback has been acted on through other QTE activities.
Apr 10 2020
Apr 9 2020
Apr 7 2020
Apr 1 2020
One approach to this could be simply doing a live stream of the train on a regular basis vs a scheduled "workshop".
Mar 31 2020
@Aklapper, yes I found it -> https://drive.google.com/file/d/1F8dPFcbzVnAle55_j-Mhilfyx0pKp0et/view
Mar 30 2020
Mar 27 2020
Mar 23 2020
Mar 20 2020
As to the question of what's germane to the Structured Data team, there's a reasonable argument a good chunk of it is, although certainly not all of it.
Mar 18 2020
@Jrbranaa point of clarification: this is a custom SLO for the extensions. What do you recommend for the columns of "Code Stewards" and "Maintainers" given this disposition? I got the impression that it would be easier to just link to Structured Data in both columns rather than set them both to "Unassigned" or one to "Structured Data" and one to "Unassigned" depending on the state of active versus inactive development. I ask that once this is defined then @MarkTraceur update.
@dr0ptp4kt, if this is just a question about a lowered SLO/de-prioritized work, then I think SDC remaining in both columns makes sense. That being said, my expectation would also be that any outstanding work on the affected components/extensions would be surfaced during annual planning as a gap. Whether or not it is prioritized is a different discussion :-) In the end, we still need/want someone to monitor the ongoing needs of the code and be a point of escalation if need be.
Mar 12 2020
@Mhurd per our discussion, we'll schedule this topic for our QTE Office Hours on the March 20th. I'll send out a note announcing it tomorrow.
Mar 6 2020
Recently had a discussion with @mark and @faidon about some work that SRE is planning to do. Specifically the creation of a Service Catalog. On the surface this seems like it would potentially become the ROO mentioned in this task.
Mar 5 2020
Mar 3 2020
Feb 27 2020
Thanks the looping me in on this discussion. As I've been hearing rumblings about the lack of code stewardship on various MM components, I'm already somewhat aware of this gap. I'll be broaching this topic with the soon to be formed Code Stewardship Review Committee. I've already had some discussions with @Krinkle on what I believe to be related issues. In the meantime if you could @Ramsey-WMF or @dr0ptp4kt, please update all the items on the developer/maintainers page that you believe the SDC (formal MM team) will no longer be supporting (mark as "Unassigned" with red background). This will help bring clarity to the specific components/extensions that are orphaned as a result of this team change.