Jump to navigation Jump to search
Previous Action Items
- Eric to go over and document "Create testing roadmap as an example of how to document architecture (this is will be an outcome of testing meeting"
- Make Matthias make sure our documentation (README / config instructions) is up to date after latest release (j/k all devs)
What are we doing that we should keep doing?
- Catching lots of stuff in QA! Both because our process is tighter and because the things we are working on are bumping up against more things that weren't designed to work with it. Good job everyone!
What are we doing that we should stop doing?
- Related to Nirzar's feedback on qualifiers:
- Had a different understanding of how serious a blocker should be (also: what makes a blocker a blocker?)
- Having unclear criteria for success is a recipe for failure
- Working with uncertainty about who we are supposed to design for
What aren't we doing that we should we start doing?
- Get stakeholder (Nirkatz) feedback asap (and have a synchronous meeting about the underlying problem(s) vs just focusing on one solution)
- Make time to plan set things up approrpiately before each release.
- Make time to extricate design/layout code from ... < ERIC PUT THINGS HEEEEREEEEEE
- Issues in the code that could be improved:
- start using templates, and de-couple layout code from logic wherever possible (this can be done in both JS and PHP)
- consider using a consistent naming convention for CSS classes (I would propose a loose BEM style to clearly indicate heirarchy)
- better automated test coverage
- greater isolation of components (minimize calling of internal methods from outside the class, etc)
- impose consistent data flow, data types wherever possible
- try to move API requests to a limited number of places to better manage
- change some of the code linting ruies if they are getting in the way of any of the above
- Also, having a chat/tutorial about Wikibase JS datamodel classes (and maybe creating some documentation for this, since existing docs are pretty sparse) would be good
- We do need to push out other statements, but should have time to work on these things after that, early to mid July
- Use the Tuesday story meetings for talking through code health stuff if there are no stories to work on
- Revisit how to improve code health early to mid July