Hitachi Vantara Pentaho Community Wiki
Child pages
  • Story Acceptance Criteria

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Projects that have downstream dependencies (Commons, Pillars)
    • testing should be conducted not only on the current sprint's requirements but on all uses, unless a rigorous test environment is created for the project increasing the confidence of stability for the commons project
    • API changes to these projects should only be made in Major or Minor releases, not patch releases of the project
    • Many times commons projects are not branched for patch releases, we need to be conscious of downstream branch dependencies.
    • Please see the CI dependency report to determine downstream dependencies of projects
  • Code Coverage verification
    • coverage verification will be determined on a per story basis initially.  This may be included as part of the ci or nightly builds depending on the projects involved.
  • Code Reviews
    • The goal will be to do team oriented code reviews, based on the above criteria.  As we work on creating a more comprehensive detailed list of criteria.  Marc will also participate in code reviews as requested and necessary.
  • Handling of bugs during sprint process
    • Product Owner working with Team Leads will determine if the bug is a blocker for story acceptance or if a JIRA case spanning sprints is acceptable for bugs created and discovered during the sprinting process.
  • Remote Considerations - making sure these processes are visible to the community and to work-from-home developers