Topic on Talk:WMF product development process

This is a product development process, and that means that we need a good, shared understanding of what a product is.

Below is an alphabetized list of things that might be "products" for the purpose of this process; I believe that most of them are. Are there any items in this list that you think should not be covered by this process? Are there any items in this list that you suspect would receive little or no engagement from typical contributors? Are there any products (on or off this list) that you would recommend a different process for?

• Article Feedback Tool
• Compact Personal Bar
• ContentTranslation
• Echo (Notifications)
• Education Program
• Engagement metrics
• FlaggedRevisions and PendingChanges
• Flow
• Forced HTTPS
• Gather
• GettingStarted
• GuidedTour
• HHVM
• Image filter
• LiquidThreads
• MediaViewer
• MobileApp
• MobileFrontend
• MoodBar
• PageImages
• PageTriage
• Parsoid
• QuickSurveys
• RelatedArticles
• Scribunto
• SUL
• SUL finalisation
• TextExtracts
• Thanks
• Typography refresh
• UniversalLanguageSelector
• UserMerge
• VisualEditor
• WikiGrok
• WikiLove
• Winter

I'm not sure that SUL finalisation counts as a "product" for the purpose of this proposal. There's no possibility of a "maintenance phase". It was a one-time event, rather than a product (although some software and scripts were created to automate some of the tasks).

What do you think?

I know it's not this simple, but maybe products are things people touch our interface with, while the other things are infrastructure?

• HHVM - infrastructure
• Echo - product
• SUL implementation - product
• SUL as a thing moving forward - infrastructure

"Any tech change which is bound to impact wikis users' experience"?

"Any tech change that affects a user's experience" means, well, "any tech change".

@CKoerner (WMF), I think that major infrastructure projects are meant to be covered. Wikipedia editors might not care about infrastructure, but it should presumably follow this process anyway (just with a reasonable expectation that the core volunteer communities won't care very much about most infrastructure changes).

I'm pretty sure there may be changes which people would have no way to detect unless we told them. That a certain feature is now written in a programming language rather than in another may be the easiest example.

I think it is useful to offer a common process for all Product and Technology projects, where each project takes the checklist points that affect to them and skips the rest. If a project doesn't have any impact on end users, only on developers, then they could skip the part related to involving end users and editors, but they still would need to go through other checks, like architecture, performance, deployment plan...

A process that allows teams to completely skip some points may be sensible, but it tends to make the process unpredictable. Also, what if I decide that (for example) performance is not relevant for my project, so I skip that step, but someone who works in that area later decides that I was wrong? How can I be certain that it's safe/appropriate to skip a potential stakeholder without actually contacting that stakeholder?

Every stakeholder should define the conditions of their requirements in their checklists. For instance, Community Liaison's requirements (the ones we put on behalf of the communities) should be reflected at WMF product development process/Communities. If a condition is ambiguous (i.e. one could say "Relevant stakeholders have been invited" leaves too much room to interpretation) then we can edit the checklists and make them more precise.

Also, reviews are expected along the process. If a project didn't have a performance check but then later in the process a stakeholder has a problem with this (or the tests results show performance issues), they will need to get that performance check, or at least have a discussion whether they should do that check or not.

If we create a flexible process, then we create a process in which you can take reasonable steps and I can claim later that you acted badly.

If we create a "precise checklist", then we create a process that overburdens most products in the hope of being barely adequate for the biggest.

I am not certain that having a single process is necessarily appropriate. What's needed for, say, PageTriage, is really quite different in both quality and quantity from what's needed for, say, MobileApp, which in turn is different from ULS. At an abstract level, of the sort that you'd find in the first chapter of a beginner's textbook on software development, there are certainly some commonalities, but the application is quite different. PageTriage needed to make a dozen highly communicative English Wikipedians happy. MobileApp needs to make thousands of non-editors happy. ULS needs to avoid making the wikis unreadable for readers and editors alike.