Actions

Developer Area/Developer Meetings/80: Difference between revisions

From Mahara Wiki

< Developer Area‎ | Developer Meetings
No edit summary
No edit summary
Line 73: Line 73:
* images/image gallery
* images/image gallery
* journals/journal entry/tagged journal entries
* journals/journal entry/tagged journal entries
== Next meeting and Chair ==
[https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200908T1930&p1=22 Tuesday, 8 September 2020 at 7:30 UTC]
Chair: Kristina Hoeppner<br>
Minutes: Robert Lyon<br>

Revision as of 15:01, 23 July 2020

Agenda for the 80th Mahara developer meeting on Wednesday, 22 July 2020, 7:30 UTC

We will meet using Big Blue Button (Kristina will initiate the call).

Our #mahara-dev channel on Freenode IRC will be our backup or in case there are problems with the web conferencing tool and we'll need to chat to resolve it. If you don't have an IRC client, you can join us using your web browser.

  • Robert Lyon, Catalyst IT, Wellington, New Zealand (Chair)
  • Cecilia Vela Gurovic, Catalyst IT, Wellington, New Zealand (Minute taker)
  • Kristina Hoeppner, Catalyst IT, Wellington, New Zealand
  • Russell Boyatt, Uni of Warwick, United Kingdom
  • Phillippe Adrian

Agenda

  • Items from the last meeting:
  • Mahara 20.10 roadmap
  • WCAG 2.1 progress
  • Mahara assignment submission plugin
  • Any other business

Minutes

Items from the last meeting

Where to upload recordings

  • Need more info from sysadmins before proceeding

Resume change ideas from Russell

  • Still work in progress
  • Strategy: The idea is to have custom fields. If a field is used in any way then it will be retained as a custom field, changing the nature it's stored.
  • question: From the fields we have now, should they be retained as custom fields even if they're not used?
  • agreed: If they're not being used then they can be dropped. Marital status, visa status and gender could even be removed from new installs. There should be a warning on the manual if this gets implemented.
  • question: what happens with existing fields that are not as simple as text? do we need custom types as well?
  • agreed: have free text fields for custom fields
  • question: if all existing fields are retained, can the site administrator delete them?
  • agreed: the problem with this would be if the field is being used, then all information would be lost. One option would be to show the site admin the number of accounts that are actually using the field so the admin knows which fields are not used and are safe to remove. If there are just a few accounts using them, then the owner of the account can be contacted directly in case the custom fields needs to be removed.

On new Mahara installs, the pre-populated fields would not be even present. On upgrades, the existing fields would be retained but the type would be changed to free text field.

Mahara 20.10 roadmap

Submission plugin

  • The plugin has been updated, this is a new version for the moodle-mahara plugin. You can find it here https://github.com/catalyst/assignsubmission-maharaws . The Archiving of submissions hasn't been implemented yet. Needs Moodle version 3.5 or newer. With this we are closer to the removal of Mnet.

Roadmap 20.10

Including:

  • Layout spacing between blocks issue
  • New Mahara mobile app
  • New Mahara theme
  • Portfolio submission extension
  • SE editor refactoring
  • WCAG 2.1 accessibility requirements
  • Many improvements in styles (order of headings will not be included, but moved to 21.04)
  • Looking into moving from launchpad to gitlab for bug tracking and wishlist items (need to sort out authentication)
  • Library of Mahara components

Client work not included on roadmap yet:

* Quick editing of text boxes
* Link to authentication method: Mahara will redirect depending on the authentication the account is using

Questions

  • question: Is the additional theme going to be the new default?
  • No it will not be the new default theme
  • Every theme will have the same accessibility features
  • accessibility: is really good to see the complete list of what is needed to see what we already we supply and have a complete list of all things we need to change. We can follow the progress more easily. Also prioritize the difficulty of implementation and the need for them

Other businesses

  • question: Do we need the full resume block?
  • The resume block type is not good because it has a pre determined structure which is not ideal for all countries. What happens is that people prefer to add many single resume field blocks to define the structure they need. We still need to check anonymous statistics of sites to see what people use.
  • agreed: Deprecate in for example one year and then remove it from the code. For new instances, the block is hidden. For upgraded sites, if the block is used, show deprecation message.
  • idea: consolidate following blocks
  • embedded media/external media
  • images/image gallery
  • journals/journal entry/tagged journal entries

Next meeting and Chair

Tuesday, 8 September 2020 at 7:30 UTC Chair: Kristina Hoeppner
Minutes: Robert Lyon