The session proposals will be added to this task tomorrow and an email will go out to techconf attendees asking for feedback on theme and session proposals before they are finalized.

@kaldari I've dared to make a suggestion of a possible session that I believe fits the Standardization theme the best: T234957. Feel free to move to another theme, or dismiss the idea.

The one topic I'm missing a bit is how to get more involved in global standardization efforts (such as W3C).

In T234090#5571471, @Tgr wrote:

The one topic I'm missing a bit is how to get more involved in global standardization efforts (such as W3C).

Have you seen the tech talk?

https://etherpad.wikimedia.org/p/Standardization_Decisions

In T234090#5667973, @WDoranWMF wrote:

https://etherpad.wikimedia.org/p/Standardization_Decisions

Copied here:

Standardization Decisions

• Front-end modernization and standardization
  • 3 questions:
  • If you had all the resources, how would you envision a user frontend system?
    • A clear API exposing all the data
    • Flexibility of where the interface is rendered. Isomorphic rendering.
    • Modular code that you can add new components to
    • Edge-level composition to remove log-in penalty
  • Why haven't we done it yet?
    • Already invested in in-house frameworks (OOUI)
    • Try to stay backwards compatible
    • No good separation of concerns in MediaWiki
    • Requirement to support non-JS users
    • Need broad consensus for changes
    • Lack of infrastructure for migrations
  • What should we think about when we consider the next steps?
    • Keep things moving
    • Make it easy for others to build on top of
    • Figure out how this will affect gadgets and user scripts
    • How can we reduce risk?

• Learning how WMDE improved their organizational structure
  • Poorly defined processes and lack of adequate management
  • Adopted Scrum + Kanban
  • Adopted Journey model - hiking and camping metaphor
    • Campsite - Maintenance, bug fixing
    • Hikes - Product presents a feature idea and forms a team
    • Trailblazers - Someone presents a technical issue to tackle and they form a team
  • Benefits
    • Smaller teams with team leads
    • Better support for employees like regular 1:1 and team meetings
    • Regular feedback cycles
    • More dynamic and flexible
  • Outcomes?

• Standardizing QA best practices
  • Worked on creating a shared understanding of key issues related to current QA practices:
    • The principles of QA testing
    • What needs to be tested
    • How does exploratory testing fit into the development and deployment process
    • What do teams need from QA engineers
  • Action items:
    • Continue discussion of QA practices in a broader context of Engineering productivity team
    • Start a discussion of specialized types of testing - e.g. Accessibility - and how to make them a part of QA testing
    • Document what instrumentation/tools/skills/practices are critical for efficient exploratory testing

• Componentization and sharing with the open source community
  • 4 questions:
  • What are the benefits and disadvantages?
    • Various benefits and disadvantages were given.
  • How can we make usable components to share?
    • Package and release it to package managers
    • Need better documentation and demos
    • Make it discoverable and promote it widely
    • Make sure it has a Project Manager and dedicated developers to maintain
  • How can we monitor usage of shared components?
    • Various ideas
  • What existing components should we share?
    • Banana, pure js client for message localization system (i18n)
    • Universal language selector
    • UI for wikidata query service (data visualization)
    • OGV.js, pure js webm reader
  • This needs to be made into a document that can be used by decision makers.

• Mediawiki Code Ownership
  • Discussed differences between ownership and stewardship
  • Split up into breakout groups to answer the following question:
  • What are some logical ways to segment MediaWiki? What are the pros/cons of each approach?
  • Group 1
    • By functionality
    • Need ability to watch specific segment, perhaps as a board or repo
  • Group 2
    • By Developers/Maintainers list (already exists)
    • By contributors
    • By feature map
    • Use structured data
    • Use herald rules
    • Need more boundaries through decoupling and componentization
  • Group 3
    • By classes
    • By components
    • By use-cases/personas
    • By date or "last touch"
    • By skill sets
    • How do we deal with cross-cutting concerns, like caching, load balancing?
    • Stewards should be teams/collections, not individuals

• Notes:
  • Group 1(Hickory)
    • What are your main takeaways from the sessions in this theme?
      • Kosta: Vague outcomes, curious if others have that impression
      • Timo: Componentisation of Core, in terms of redrsawing boundaries closing the gaps so there aren't unmaintained parts. We have special pages but that might as well be called PHP it's not ownable. Moving rc filters and it's schema and api module into a single structure so that it's logically associated
      • Daniel: Where do unconf sessions fit into this? If they did the one on RfCs would have matched the theme. What stood out for me, while we have big problems we do have things we can actually release - for example - never knew about banana. Looking at how that would be reused, that is something to look at as part of the FAWG. If we build more interfaces we need localisations
      • Ryan: If we can get things proposed as standards, unicode consortium might be interested in banana. 
      • Timo: There is the assumption that there are plural grammar and gendered language. 
      • Ryan: It might fit in with the cldr stuff unicode manages
      • Daniel: I would be very interested in how that would work and if we could get standards at least internally
    • What topics, action items, etc. have we missed in this theme?
  • Group 2(Magnolia)
    • What are your main takeaways from the sessions in this theme?
      • Really like the idea of components but this demands lots of resources, and I thought we weren't able to do this because of our resource limitation. If you go to a react framework site, they have a lot of videos, tutorials and support. You need a whole team to be able to support an effort like that
      • I think it was good that they came up with a list of options even if we don't yet have the resources, as we could look for the resources in future discussions
      • Really liked the QA sessions, we should do more similar sessions, applicable to those already doing tests. 
      • Liked that there is someone on a rotating basis being responsible for reactive work
      • Really enjoyed the WMDE session, really happy they brought it to share with everyone
      • Code ownerships was a good important discussion, would like to see us move it forward
    • What topics, action items, etc. have we missed in this theme?
      • There were some great discussion about componentisation, what are parts of MW that we do so well that other people might use them. I would also have liked to see us ask what can we do to meet the expectations of modern developers, what are the gaps
      • We should have session for educating developers how to do testing on the various parts of the code base
      • How do you tag the WMDE campsite team?
        • You can tag them and they'll triage
  • Group 3(Oak)
    • What are your main takeaways from the sessions in this theme?
      • Great discussions within the sessions
      • Really enjoyed frontend modernisation discussions, feel like we're getting closer to a shared understanding, also because the technology moved on
      • Struck by the number of different ways we could maintain the software better, there were a broad set of options and it was hard to find the commonalities or the ability to compare and contrasts
        • Might be complex rather than complicated
      • For ownership, I don't see a way that we join forces on how code ages, especially 3rd party dependencies. How we track when this happens and how this is pushed back into the team?
        • Rather than a 0 day happening, how do we automagically route this information into the team
        • Github provides some means
        • There is no standard across our teams, better if teams don't come up with their own versions
      • Appreciated JS framework discussion at unconf
    • What topics, action items, etc. have we missed in this theme?
      • Action items weren't clear, not clear what follows from this. May be the session leads can summarise a bit more clearly what we can do with the discussions
      • Some of the problems are very broad and over reaching yet there is no one responsible for taking on the over reaching element
        • May be require higher level intervention/ownerships
  • Group 4(Azalea)
    • What are your main takeaways from the sessions in this theme?
      • I love the accessibility as QA, this is a great chance for us
      • WMDE process:
        •  I thought that was an awesome idea, trying to figure out how we make it work on my(Cormac) team
        • Breakout sessions that are themselves hikes
        • I liked that the maintenance part was built into the model rather than an after thought
      • Componentisation always a good idea, needs resources and decisions
        • Follow up should be to create a project proposal and to move this forward
      • Surprised there were no discussion of JS frameworks but there was kind of a discussion in an unconf
    • What topics, action items, etc. have we missed in this theme?
      • The design and UX part of the frontend part was kind of missing, there are a lot of technical decisions that will be influenced by design and we didn't have enough time to dive into those
  • Group 5(Bosewood)
    • What are your main takeaways from the sessions in this theme?
      • WMDE, wasn't there but thanks for the summary, suddenly a lot of emails make sense
        • There is a good blog post by Raz who implemented it, we will add it to the notes Raz's blog post:
          • https://somehowimanage.blog/2018/06/26/the-journey-model/
      • Components there but librarisation didn't happen, there is more maintenance once it becomes a library I suppose
        • One thing we may be shouldn't bother doing, instead do the development in MW then copy it out to another repo and then release it
        • Does it need to be even in another repo?
          • For composer, yes
          • For npm, no
      • Was there narrowing down from the possibilities for code ownerships?
        • JR: not really, but there was a lot of opportunity for overlap
          • One of the directions people were starting to lean was how would we approach this in a shared stewardship model
          • But make it as clear as possible who you could go to in these different scenarios
        • JR: One thing I found interesting was having the meta data within the repo
          • Ryan: Yeah to roll that up from the code into an interface would be really cool
          • JR: Maintainer page is manual so out of date, generally. Would be nice to support automatic update
        • JR: there wasn't general consensus more that what we choose needs to be straightforward.
        • JR: Also need more definition in what exactly a code steward is
    • What topics, action items, etc. have we missed in this theme?