Thanks @Eazeeee. I concur.

Approved

Approved

Approved.

Approved

Manager Approval if needed.

In T247665#8101851, @NancyCole1 wrote:

Uhm, I don't know if google is the best option for storing the insights

+2 approved for @EAkinloose

@EAkinloose or @zeljkofilipin, can either of you take a look?

I have removed myself as the assignee of this task. Once our new software engineer in test starts, I will have them check into this task to see if we should assign ourselves to it again.

Thanks @Aklapper, I believe that the Code Governance Policy being proposed is trying to address the same core problems as the Code Stewardship initiative. Perhaps the appetite for solving this problem has changed, but unless it has, I believe that this policy will also encounter the same hurdles. The Code Stewardship initiative has definitely encountered challenges as of late, but I still believe that the approach is sound.

Hi, I'm working with Derrick to help address the test environment gap. Are there any special environmental needs for this kind of testing? I know that this task speaks specifically of Beta Cluster, but I am wondering if we could satisfy these needs outside of BC.

@LSobanski Approved.

Without seeing this phab task or reading the decision statement I started playing around with https://backstage.io/ and created https://backstage.toolforge.org/ which is currently powered by https://gitlab.wikimedia.org/addshore/backstage

Going to read the doc that is here now

@Jrbranaa perhaps the for-of loop rule should just be disabled.

Yeah, makes sense to me. I'll take a look.

@Majavah - yes, this work has stalled due to a shift in my priorities over the last few months. However, it's back on the "front burner". I think it makes sense for this task to remain open until a plan has been pulled together and published.

@sdkim this is similar/related to T190891. The scope of concern might be a bit different, but it seems to make sense that these should be related. The Canonical Service Catalog work also seem to be very closely related to the Code Stewardship initiative. Probably worth talking a bit about how these efforts could at a minimum be coordinated.

I don't believe there are any additional actions to be taken.

@thcipriani do you think this is something that someone on the RelEng team could build out and possibly host?

@thcipriani do you think this is something that someone on the RelEng team could build out and possibly host?

I think codifying things like this makes sense. I'd like to also explore other potential attributes that could help establish severity. I've given frequency attribute a name - Error Arrival Rate (stolen from Defect Arrival Rate) :-) These may prove to be a bit more difficult to identify and analyze, so we'll need to take that into consideration. In any case, we'll need to figure out how to perform said analysis with minimal impact to the train conductor.

Sorry for the delay in response on this task. The Code Stewardship Review process has definitely run into some snags over the course of the past year as there's been a reduction in our capacity and as a result, an inability to find Code Stewards for many of the outstanding items. That being said, there's been a significant amount of activity and discussion around the topic of Code Stewardship as of late and we will be discussing all of existing orphaned code during our annual planning process over the course of the next several weeks. As a result, I hope to have a path forward for this and other orphaned code in the not-to-distant future.

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.

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.

@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.

@thcipriani and @greg this is the task that prompted the SonarCloud product ownership discussion and subsequent email to y'all.

@Jpita, probably the best person to talk with is @Mhurd (Monte). He did some research on this early on and might have some thoughts.

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.

Approved on my end.

@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?

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.

@kostajh @Gehel, are either of you available for a Code Health Office hours on this topic the week of April the 26th? If so, any particular day better than another?

One approach to this could be simply doing a live stream of the train on a regular basis vs a scheduled "workshop".