Talk:Product Tech Steering Committee

As a newbie reading through this for the first time, I noticed we seem to be interchanging the words "Product" and "client" teams quite often which led to some confusion on my part. I'd like to propose we make the language more consistent throughout and perhaps add these to the 'definitions" section so it is clear the role they are playing in this process when we use these terms? @NNzali (WMF) helped to clarify that they can be synonymous.

Example 1: The Product team submits an API initiative request by creating a Phabricator ticket in the Untriaged column on the Platform-Product Roadmap Workboard here, ideally no later than 3 months before stakeholders expect to start using the API to give the team responsible for building the API enough time to plan and execute. As stated earlier, the development and client teams work together to build the API, including frequent client reviews, feedback, and demos throughout the API initiative implementation.

Thank you, @DAbad (WMF). That's a good suggestion. Where should we put this section on the page?

@SKim (WMF) do you have any comments?

@NNzali (WMF) I'd imagine we should put it under the "Definitions" section under where we outline API, capability, and platform? Or we could add a roles section?

Have we thought about using a prioritization matrix to visualize how the initial prioritization process will work so it's easier to digest by those outside the steering committee? Based on what we have already, I tried creating a visualization for this here: https://drive.google.com/file/d/15c0nkRck0p5Paf7zOvxgYCLEWmYUA-rb/view?usp=sharing

@SKim (WMF), @WDoran (WMF), @MNadrofsky (WMF) would this be something we can align to how we generally bucket Now, Next, Later within the teams? Or perhaps we have something similar to this already that we can leverage?

What? API Maintenance

Question from @Ggellerman (WMF): Do we also consider who will maintain it?

@MNadrofsky (WMF) and @DHorn (WMF) could you answer Grace's question?

Comment from @Ggellerman (WMF):

"Consider adding an acknowledgement that we may not know which situations would be ideal for ML and would still like to note that we see them as a factor in some as yet undefined way."

Comment from me: Could we spell out ML it"ll help everyone know what we're talking about.

What? 5. Principles on Collaboration > "Clients and API teams are expected to meet, communicate and stay updated on a regular basis."

Comment from @Ggellerman (WMF): "consider defining the minimum definition of "regular basis"

For ongoing initiatives, I'd suggest a daily async standup and a biweekly demo and retro. What do you think?

What? 3. Prioritization and Team Assignment > "What is client priority?" "Do we have skills to build the API?

Questions from @Ggellerman (WMF): Will we also consider priority to the department? That is, if a request is highest priority to the SDAW team but the Product department considers another team's highest priority request as an even higher priority?

@DHorn (WMF) and @Jkatz (WMF) could you answer Grace's question?

@NNzali (WMF)@Ggellerman (WMF) Yes. I think it should be explicit and just added it.

What? "Likewise, the API teams are accountable for running all relevant issues past security, performance and legal (often in coordination with the Client Team)."

Comment from @Ggellerman (WMF): "some more explicit expectations as to which team owns which interaction with Security, Perf, and Legal could be helpful and could also be decided later. However, we will need clear expectations by the time we are executing this part."

@DHorn (WMF), @Jkatz (WMF), and @MNadrofsky (WMF) . What are the expectations regarding ownership?

I think we saying the API is overall accountable is a good enough start for now., but if anyone else has strong opinions, I wouldn't fight more specificity

Comment from @Ggellerman (WMF): "I think that this item should be moved up to position 0 or 1. Seriously, I do!"

@DHorn (WMF) and @Jkatz (WMF), could we move this up to position 0?

I'd like to keep it under 5 for now. It is specific to #5, the how the API teams work with their clients, and really all the guidance we're offering for this stage at this point.

I would argue that this question is irrelevant. Number of endpoints in the API has very small impact on overall complexity. Amore important question by far is whether platform has backend concepts and data in the structured format to support the API. For example, creating Wikibase API with 100 endpoints is overall much easier then creating a single endpoint for image search or machine learning based suggestions.

What? Resources needed > API documentation

Comment from @Ggellerman (WMF): "is this the Tech Writers who would do the documentation or a different type of documentation?"

@SKim (WMF), @EProdromou (WMF), could you respond to Grace's question?

This is part of the API implementers' responsibility to have API in a place that client teams can use.