Page MenuHomePhabricator

Building Better Software (Hack-a-thon session)
Closed, ResolvedPublic

Description

An open discussion about what we do well and what we could do better as it relates to our software engineering practices.

Over the past few months, I've spoken to a number of people within Wikimedia Foundation with the goal of better understanding how we build software, what we do well, and what we could do better. The result of those discussions is the "Quality Big Picture" document[0]. This session is intended to be a continuation of those discussions.

Please come prepared to discuss those things that you believe are going well and those things that we could improve.

Although it is unlikely that we could cover the Quality Big Picture document[0] in it's entirety, we could select one of the topics from the document to discuss.

Possible discussion points from the QBP document [0]:

  • Culture/People
    • QA Tribe
    • Tech Talks
    • Code Health Group
  • Process
    • Estimation
    • Bug/Defect Management
    • Test Metrics
    • Test Strategy
  • Tools/Tech
    • Environment Parity
    • Robust Test Data
    • Long-Term data retention
    • Data visualization

For more details about any of the above discussion points, please refer to the Quality Big Picture document[0].

[0] https://docs.google.com/document/d/1AAFQNZt36TX5XVFajdbb1g-f-FSIvokhcqbBaSTXmK4/edit#heading=h.2fvj443fyzhk

Event Timeline

Jrbranaa renamed this task from Building Better Software to Building Better Software (Hack-a-thon session).May 19 2017, 10:05 AM

I've scheduled the session for Sunday morning at 10 in Powidl.

greg triaged this task as Medium priority.
greg added a subscriber: greg.

Any needed follow-ups from the session?

Notes from the session.

About 10-15 people total, as far as I could tell about half or them from WMF.

jr: an general overview of The Document

  • the fact that mediawiki has to run in various environments makes it more robust
  • how do we engage with the community?
  • for example, should we make sure that mediawiki works in shared hosting?
  • if we only focus on mediawiki running on wikimedia production, it would make the job easier
  • is there a way that the community can contribute?
  • some of the tests are running on travis, not only on wikimedia ci
  • is shared hosting support a priority and what concerns the community has?
  • how much do we know on how shared hosting has changed in the recent years?
  • can we get some metrics about shared hosting (php version....)?
  • wikiapiary or some other solution (ori has been working on something)
  • it would be easier for the foundation if we have data and know if a smaller of bigger portion of the community is affected by the change

jr: I hate to bring up containers, but a Docker based solution could help the community (pulling the images the foundation has created)

  • how much the diversity is intentional, and how much is accidental, because it is the easy way
  • it would be good if a small installation would be a similar to wmf

jr: what is the structure of the audience: mediawiki developers, people installing mediawiki for organizations, people using the api

  • rewriting stuff (xtools is rewritten for the third time)
  • it would be great if the tools directory displayed metrics about the repository visible (test coverage...)
  • what would be people looking for when looking for a tool (number of downloads, ratings...)

greg: cloud team is working on best practices for tools (code in a git repository, it is public, it has a license...), the next step would be surfacing their testing practices
jr: what are some other things that would make your life easier developing/deploying?

  • the topic of test data would be interesting - I am testing an extension that is doing something unusual, and I need test data

jr: a first step could be collecting as much data as possible, then later figure out how to use it (dashboards), analytics could help

  • one thing that comes to mind are wordpress plugin beta testers, volunteers applying for pre-release versions of plugins

greg: we have beta features
jr: wordpress over time has moved to hosting wordpress.com but for a long time their goal was for wordpress to be easily installable

  • code quality of wordpress is horrible as well (like mediawiki), but the users (even developers developing plugins) do not see that

jr: how to provide pointers to design patterns?

  • tools like striker (?) helps with creating new tools (creates a repo with license, readme file, language specific files), similar to what github does when creating a repo