QA Team open space

published Oct 16, 2015

QA Team open space at the Plone Conference 2015 in Bucharest.

Manual QA: install prereleases when Eric Steele announces them? Partially. Also: make sure people other than consultants can use it, so having updated documentation, if only a note that most add-ons have not been updated yet.

We had a Launch Team, with representative of other teams. Can we turn that into a QA team? Meeting say once a month, coordinating, checking if existing teams can handle things.

Isn't it then a Process Team? Another layer. Multiadapter.

Sounds a bit like a daily executive team.

No, the release team may say we are ready for a release. But then we need to check with other teams. The technical side has a process, but the non-technical side not really. With Plone 5 a lot of technical stuff has happening and the non-technical side was rushing along trying to catch up.

The hotfix was there, the community was informed. But then there were updates to the hotfix and the communications team was not informed.

For releasing, we may start doing real alpha, beta, release candidate releases, and then do an actual final release with only a version number change. That may also give you time to update other parts, like communication and docs. And you can tell the release team to hold off. For docs, we need to include the latest stuff, even if it is automatically, but we need a moment to check it.

Problem is when technical is moving along fast and other teams cannot catch up. Technical is used to just pushing on regardless.

Have email addresses for teams.

Changelogs: declare if something is a bug fix or feature or something else. Check this automatically if possible, see if it is declared. Have best practices. Have a CONTRIBUTING.rst file in each repo: this automatically ends up on github when creating an issue or pull request.

Make it visible if all teams are ready, whether manual or automatic.

For major releases, you can prepare better, because there should be plips.

What checklists do we need?

Communications team:

  • Input: changelog, the interesting 'cherries'. Saying how to get to the new features (go here, check this box). For changes: is it a feature, a bug fix, is it for developers or end-users.
  • Output: news item, newsletter, social media, progress report, update feature list on What's in it for end-users, developers, that decides what output we need. How are the changes significant.