2014-08-07 Developers Forum

Owned by Burke Mamlin
Last updated: Aug 07, 2014Version comment
4 min read

How to Join

 Click here to expand...

 

By Browser

By telephone

  • US telephone number: +1 201.479.2627

 

Agenda

  • Quickly review previous meeting minutes (5 min)
  • Review next meeting agenda

Minutes

View at pad.riseup.net (during OSUOSL outage)

 

OpenMRS Developers Forum 2014-08-07
Recording: https://connect.iu.edu/p7tsyqwgsz9/ (Flash) or http://goo.gl/Vmp9lK (audio)
Attendees
  • Burke Mamlin
  • Willa
  • Wyclif Luyima
  • Michael Downey
  • Elliott Williams
  • Ryan Yates
  • Karl Wurst
  • Geoff __
  • Darius Jazayeri
  • Daniel Kayiwa
  • Paul Biondich
  • Vaclav Krpec
  • Alexis Duque
Agenda & Notes
Last Week TODO Review
  • TODO: Chris to schedule how Reporting in OpenMRS 2.1 will get done (or find out if Darius is going to address reporting for 2.1)
  • TODO: Burke & Darius need to pair on getting test environment working => Done
  • TODO: Wyclif to help schedule review of account manager on a design forum. (not yet done)
  • TODO: discuss scheduling of allergy sprint on http://om.rs/dev (to be scheduled) => Announced already
Community Infrastructure Team Update
  • 2,000 (automated & manual) cases in new helpdesk system since end of 1Q!
  • OpenMRS Talk (Discourse) launched, working well, V1.0 release due this month
  • Mailing list meets web forum - pick your interaction style
  • Integrated with OpenMRS ID
  • Experimental "badge" platform
  • Retiring OSQA (no longer maintained), spinning up "Ask OpenMRS" on Wiki
  • New system from Atlassian, lots of UI/UX improvements coming
  • Lots of open questions - please help our customers!
  • Support communication platform powered by status.io (Thank you!)
  • Overview of infrastructure status, outages, maintenance, etc.
  • Super-interested people can subscribe to updates through the site
  • Could use improvement! Let us know your thoughts.
  • 2H2014 priority: Improvement, scaling, growing leadership
  • Lots of new volunteers have committed to the team
  • Volunteers offering on average 10+ hours per week
  • Developers should consider following a similar model for OpenMRS projects!
  • Projected team size at end of year: ~10 volunteers
  • Clearer focus areas with volunteer leadership opportunities
  • Reliability, Security, Networks, Systems 
  • Change management, vulnerability, firewalls, DNS, sys admin, etc.
  • Leader: TBD
  • Peers: TBD
  • Real-Time Support 
  • Helpdesk/Desk.com, on-call support, outage response/restoration, performance monitoring
  • Leader: TBD
  • Peers: TBD
  • Dev Tools
  • JIRA, Nexus, GitHub, desktop tools
  • Leader: TBD
  • Peers: TBD
  • Communication Systems 
  • Wiki, Discourse, OpenMRS.org, blogs, IRC, lists/groups, social media, email
  • Leader: TBD
  • Peers: TBD
  • Identity Systems
  • ID Dashboard, LDAP, oAuth, Modulus, system integration
  • Leader: TBD
  • Peers: TBD
  • QA Systems
  • Bamboo, CI/CD support, performance testing support, DTE/INT/UAT systems
  • Leader: TBD
  • Peers: TBD
  • Coming 3Q2014:
  • Planning a new launch of OpenMRS.org integrating OpenMRS Inc.
  • OpenMRS Blogs platform for contributors
  • Evaluation of some improved software documentation tools
  • Training of new volunteers
  • Application, OS upgrades
  • ???
  • Profit
  • Questions
  • Are there servers for quickly throwing up a developer test environment?
  • Also, take a look at DigitalOcean.com for quick/temporary hosting (cheap and instant)
OpenMRS Module Directory & Modulus Development
Focus: What we’ve done & where we’re headed. 
Elliott wants you to be thinking about what you’d like Modulus to do, and whether you think the project's priorities are right.
  • New functionality since last time we talked:
  • User self-service for uploading new modules and releases
  • OAuth Authentication with OpenMRS ID
  • Multiple user can “maintain” a module
  • Module owner can be a non-user (for example, an organization)
  • Module data is populated with data from config.xml
  • Next steps:
  • Detecting old & unmaintained modules (see question below)
  • Could be implemented with tags
  • We’ve had a mockup of a new home page, waiting for someone to help implement
  • Any volunteers?
  • Next next steps:
  • Nice to have, but not top-priority
  • Future development:
  • Making it easier to "onboard" new developers
  • Vagrant
  • Nitrous.IO Hack button
  • Web-based IDE with an "instant" Modulus dev environment ready to go
  • TODO: Publish Nitrous.IO usage instructions
  • Docker? :-)
  • Making it easier to develop
  • Good documentation - for the API, backend, and frontend. URL: __
  • Documentation in process for Grails/Angular apps. URL: ___
  • New Infrastructure team volunteers will help make these ideas a reality
  • >= 1 CIT volunteer will be hacking on Modulus/UI
  • Are you one of them? :)
  • Questions:
  • OAuth seems to be needed nearly every time I log in.  How long should auth last?  I would be fine with 12 months.
  • Should users normally be signed in when visiting the site? Maybe too easy to edit? (Design question) (Burke believes "too easy to edit" would be wonderful to have)
  • (Burke) I would prefer 12 months.  I am not worried about bank-level security of my module metadata.
  • Need to be able to cancel editing
  • How to track "activity" on a module?
  • Uploads/release count/date?
  • GitHub repo commit activity graph?
  • Have a service that, given a module ID, reports basic metrics on "recentness"
  • What's the best default view/sort for presenting modules?
  • It may take some time to develop the best heuristic that combines lots of factors.
  • May be some quick wins for sorting/weighting modules.
  • Should deployment be a top priority?
  • Burke: it's not that hard to upload an OMOD
  • TODO: We need a user story in the MOD project for this scenario
  • Uploading vs. create new module
  • UI needs work
  • How can we improve the process for determining next priorities?
  • Polls & JIRA votes: encourage community to vote; "approach key stakeholders" for their input
  • Top priority (according to community in this meeting):
  • Improved sorting and categorization
  • "What is new and active vs. old and unused"
After Action Review
  • What did you expect to happen?
  • What actually happened?
  • What can we do different?
Preview next meeting agenda
  • Sprint Update
  • WIP: OpenMRS in Keny

TODOs

Transcripts

  • Audio recording of the call: Listen online or download (available after the meeting)