Page Comparison

Date

13/Jan/2011

In Attendance

• ??~michael
• ?~wyclif
• ?~jeremy
• ?~burke
• ?Shaun Grannis
• ?~r.friedman
• ?~sunbiz
• ?~mogoodrich
• ?~darius
• ?~dawn
• ?~paul
• ??~bwolfe
• ?~ayeung
• ?~ayunis
• ?~dkayiwa
• ?~muraguri2005Michael Downey
• Wyclif Luyima
• Jeremy Keiper
• Former user (Deleted)
• Shaun Grannis
• Roger Friedman
• Saptarshi Purkayastha
• Mark Goodrich
• Darius Jazayeri
• Dawn Seymour
• Paul Biondich
• Ben Wolfe
• Ada Yeung
• Former user (Deleted)
• Daniel Kayiwa
• Richard Muraguri Gathogo

Agenda

• Quickly review previous meeting minutes (5 min)
• 1.8 Update - Wyclif
• ?Multiple providers per encounter (Design Page) (TRUNK-39) and ?Support for visits Visits (Design Page) (TRUNK-48) - led by Burke (45 mins)
• "Introduce" Daniel Kayiwa (5 min)
• After-action review & next week's agenda (5 min)

Minutes

• Time Keeper: TBD

Real-time collaborative notes - please update wiki after meeting

(15 min late starting)

1.8 Update (40 min)

• Beta is released
• RC1 coming soon. Until then, more testing needs to be done. RC1 can't be released until at least one (ideally 2+) implementations have tested.
• A recurring theme over the last several releases has been a limited pool of testers. (Implementations tend to have very limited people & technology resources to volunteer for testing.)
  • Darius: Should this type of testing happen with a RC version instead? Takes time for volunteers to test so many modules. 1.8 is likely to break some modules due to the changes in widgets.
  • Burke: Let's see what type of testing can be automated. Wyclif will coordinate.
  • Paul: Many applications (especially beyond open source communities) release without having external implementation feedback. We may be putting a non-sustainable burden on people & organizations that don't have resources.
  • Michael: To replace implementer testing at a minimum it's necessary to have a formal documented QA testing process (use cases, etc.).
  • Roger: We should communicate with module developers about the changes in trunk that could break their modules and encourage them to test/fix.
• TODO: Michael to create a module mailing (notification) list and use those listed in the module repository as initial subscribers.
• TODO: Wyclif to explicate the goals & tasks to test bundled modules in the Testing Releases page. He will work with module developers to make sure test cases are complete.
• 2 or 3 tickets not yet completed.
• Ben: Working on a patch that Upul started docs:TRUNK-26@ticket to modify the initialization wizard. This could be modified for pre-release testing that could connect to an external existing database and copy it into the virtual appliance for testing. (This functionality would only be turned on for the appliance distribution.)
• TODO: Wyclif will coordinate developing webdriver tests. Ben sent a mail to a volunteer interested in testing.

Daniel Kayiwa (5 min)

• Ben introduced ~dkayiwa Daniel Kayiwa, who is joining the core development team full time.

1.9 Design

Multiple Providers per Encounter (50 min)

• Wiki page: Multiple providers per encounter (Design Page)
• JIRA ticket: docs:TRUNK-39@ticket

Support for visits (15 min)

• Wiki page: ?Support for visits Visits (Design Page)
• JIRA ticket: docs:TRUNK-48@ticket

Outcomes

||Completed||Priority||Locked||CreatedDate||CompletedDate||Assignee||Name||
|FT|M|F|1294938703052|          |wyclif1296141346462|michael|Wyclif to explicate the goals & tasks to test bundled modules in the Testing Releases page. He will work with module developers to make sure test cases are complete.|
|T|M|F|1294938671661|1295536143537|michael|Michael to create a module mailing (notification) list and use those listed in the module repository as initial subscribers.|

Transcripts

• Backchannel IRC transcript
• Audio recording of the call: Listen online or download - available after the meeting