Presenting the Product Working Groups definition of Product Quality
Working to find the Core Product - defined in OEP-57. In other words: what’s the minimal set of features that we’d want turned on by a new installation?
how to decide? Looking at usage data, comparative research (Moodle, canvas, etc), thinking about differentiators, education research, and quality of the components
Product Quality: how good is this feature?
Product WG will want BTR WG’s input on quality of compoments, since we test them and work them into the named release
Two axes for product quality:
Audience (example: Learners
Attribute (example: A11y)
This makes a matrix, and each (relevant) cell gets evaluated, for each feature.
Case Study evaluation: Course Wiki.
There is a gut sentiment that it is “not good” and therefore maybe we should remove it from the Core.
Evaluation says…
It is accessible, i18n’ed, performs well. Not bad!
Usability: looks old, but is usable.
Scales well for authors.
Where it falls flat: it is very out of maintenance.
Overall: Course Wiki is decent, but has issues.
This gives us a more nuanced view of the feature.
Will help BTR and Product work together on deciding what gets into the Core Product (and therefore the default named release)
Only 2 evaluations done so far (course wiki, frontend-app-profile). Intention is to do it for many/all Core feature (dozens… hundreds…?).
John: Do we evaluate “Do we use it?”
Sarina:
Not as part of this Product Quality spreadsheet. This is quantitative analysis.
But it is part of the greater Core Product consideration as a qualitative feature.
Dean: It would be a great to make this line up with the test plan.
Sarina: Agreed, but not for palm.
Dean: What’s the plan for filling it in?
Conference is primary focus currently.
This is a preview to get feedback.
After the conference, regroup on a plan.
Ghassan: When it’s lined up with the test plan, it can give us two way feedback.
Pierre: Eventually, it’d be good to have the entire Core represented using this sheet. And then, after that, the next ring around the Core.
Sarina: This isn’t the only thing we would use to decide what’s in the Core. Product WG is trying to make a product that is usable and competitive, whether a feature
Kyle: Could be a signal to remove something from the core or add it or invest in it.
Sarina:
NOT let’s evaluate every feature in the platform every 6 months
YES let’s use this rubric to evaluate something when we need help deciding whether to include something in the Core.
Looking through GH to see which MFE will be tagged (not necessarily included) for Palm.
(the bold ones are ones which we think replace existing features)
Learner Dashboard
course dashboard
Communications
bulk email??
site wide announcements??
(what is it?)
ORA Grading
grading inteface for open responnse problems
Learner Record
Credentials
Publisher
Interesting that it’s tagged
Support Tools
Admin view for managing enrollments, tracks, etc
Both Frontend WG and BTR need to decide: which MFEs to include
Olive had a matrix of things-to-do which Adolfo put together. For example: translations, minimal documentation, adding to Tutor. No such matrix exists yet for Palm.
Testing
Some are replacements of current features. Testing might be as easy as : use the old test plan
Some are new feature – we’ll need to dig up docs to write tests
Ghassan: It would be good to include learner dashboard so that we can remove the old one. We will need to do it at some point.
Kyle: ORA Grading too
Ghassan: What is communications? bulk email?
Peter thinks so, not sure
Maksim: Yes, it’s about bulk email
Peter will talk to Frontend and Product WG
Dean: We could bring them in as experimental if it made sense, like we did for Olive
Form Regis: Hi gang! I'll be in a train today during the meetup, so I might be able to listen but not talk. I would have liked to discuss the devops meetup that will happen at the end of the conference, Friday next week. This concerns the BTR, but also devexp and large instances working groups. Ideally, we will be talking about issues that are relevant for many people in the room. So I proposed that we do not focus on overly technical details, but instead take the opportunity to encourage people to start new projects together. Meeting people in the flesh is a real motivation booster, I think. Thus, I'd like to suggest that we do a series of lightning talks on stuff that we would like to work on together. Lots of preparation is not expected for these talks! It's perfectly fine not to have slides. Do you like this format? Please write your lightning talk ideas here: https://docs.google.com/document/u/0/d/12bXPvpjuqRGSHBW21GY9Nsnr5eWXiQ0kwp1ZxOpnXU0/mobilebasic