Talk:Platform Evolution/Goals

The last one I see if Platform Evolution/Updates/Feb 2019. Thank you!

This is a very thorough and concise document which focuses on the right problems, whoever authored it did a great job!

One thing that I feel is missing is enabling volunteers. Currently volunteer developers are not empowered to do effective work; IMO the main reasons for that are lack of documentation, lack of support, lack of training and mentoring, and lack of code review. Documentation is called out in the relevant section, code review is sort of mentioned (although the phrasing suggests that issue there is lack of automated testing, and for volunteer patches that's not the biggest problem by far, but unclear and unequitable code review responsibilities by paid staff, and lack of agreed-on review processes like SLAs), but support (in the sense of e.g. mediawiki.org's support desk) and training/mentoring are not. Those are IMO fundamental to volunteer capacity building (they affect paid staff too, especially during onboarding, but they have easy access to informal versions of most of those).

There's also the issue of the high learning curve of our development tools (Gerrit etc), although one could argue that we can't realistically make much dent in that. Standard developer environments are mentioned, but usually that's meant in a narrower sense (stuff that runs on the developer's computer).

Thanks again :) A lot of people over the past few months contributed to the document.

I will expand the "Decrease time to integrate and deploying new features" to include:

- Code review processes and responsibilities

- Training, mentoring

I will expand "Decrease time to integrate and deploying new features" to include:

- Investing in developer tools

Question 1: Do you think those changes would cover most of your concerns? If not, do you have a suggestion?

Question 2: These outcomes are supposed to apply to volunteers as well as staff (The Goal is "Enable our engineers, staff, and volunteers to achieve our goals easier and faster"). Do you think that is sufficient or do you think that volunteers need called out more specifically?

Most of what you said was intended to be covered by those outcomes, we just didn't put enough time into writing the description, so thanks for pointing that out!

One thing I would maybe add to the list of capabilities is tools is tools for governance and management that support movement leaders and organizers. This includes things like voting systems; metrics and statistics; project management tools. (Arguably these fit under collaboration tools, but then anything that's not about readers can be argued to fit there...)

Thanks Gergo… you are right, the intention of the collaboration tools is to capture things like you mention. Do you think if I add some text about new types of collaboration tools such as you mentioned, that would be sufficient?

This seems like a fair representation of what we know today. This more abstract take is appropriate. I like the emphasis on clarifying who we're building for and what we're planning to build. In product we tend to think in the looser space of themes and problems-to-be-solved, so there's always a degree of uncertainty about what exactly we'll need, with better certainty for nearer term things. Identification of the product-market pairs is important so that the platform can be re-oriented accordingly.

The section on "Increase our technical capabilities to achieve our strategy" speaks most directly to product-market pairs from a technologist point of view. These items seem like pretty good bets. I would like to add a couple things: (1) we're not sure about the exact sequencing of this work and how the product as experienced by content cultivating communities and reusers will look. For example, although I think there's fairly universal agreement that globalization of things like templates and gadgets is a good thing, timeline and types of constructs and requirements needed to be built and enforced are still open matters (being more direct: this might be a good time to pause and consider if we want to figure out a migration path to something that better scales to the expectations of new technical and non-technical users). (2) I would recommend having a piece that speaks to ensuring it's possible to measure reuse and distribution so that we know the impact we're having - solid partnerships and relationships are important, and it's also prudent to ensure quantitative assessment of impact is possible...where possible.

Thanks Adam, this is really good and helpful feedback! To try to answer your questions:

1) You rightly point out that we don't know the solution for many of these outcomes. That may be the current system, or something entirely new. We are trying to stay solution agnostic and focusing on bringing better tooling to everyone. And migration paths should be part of any plans that we make :) Do you think we need to add anything else to make this clear?

2) We do think measurement is important to ensure progress for any of these outcomes - we wrote them in language that allows us to think about measurement. So while we are referencing measurement implicitly, we don't specifically call out establishing measurement as a practice. Do you think we should add a new outcome along the lines of "Increase the visibility of the impact of technical changes"? And we can talk about investing in quantitative and qualitative ways to measure the effects of our work?

Re: #1, I think in this high level framing it's okay, understanding that the ongoing mid-term planning will shape the verbiage further.

Re #2, I do think an outcome for measurement is appropriate - that is to say for both observability and analytic purposes.

Thanks for the input… will add an outcome for that!