...
- Now we are on JIRA, how does the team want to use the tool?
- Approach for Fedora 3 to 4 support/tooling
- Upgrade to ModeShape 4.1.0
- Tech meetings until the new year?
- ...
Minutes
- The Pivotal Tracker in previous use for tracking tickets has now been put into read-only mode. Ticket tracking has been moved over to JIRA (https://jira.duraspace.org/browse/FCREPO/). The sense is there are more community developers familiar with Jira, but more importantly that it will better support interaction from the non-developer community. Sharing the same login system with the project's Confluence wiki will make it easier for people to contribute tickets (without having to go through an additional sign-up process). Integration with the Confluence wiki, through macros, should also be an advantage. The question of how we, as a community, want to use JIRA was raised. Esme shared the workflow that UCSD uses and will get an image of their workflow as configured in JIRA. He also suggested, based on UCSD's experience, that people create avatars for themselves as this aids in the browsing of tickets (avatars are more distinctive than the generic letters that JIRA uses out of the box). The avatar doesn't have to be a personal image. If can be one of the ones supplied as default options in JIRA. There was also discussion of a scrum board, which has been configured (https://jira.duraspace.org/secure/RapidBoard.jspa?rapidView=21&view=detail&selectedIssue=FCREPO-1242). There was also some discussion about how to best manage ticket estimates (hours, points, etc.) and sprint planning workflows. Kevin asked about the RESTful API for JIRA, which is currently disabled for security reasons. He observed that turning it on would allow external clients like Worklog Assistant to be used. He said that some external clients do a better job of automating time tracking, though there are also options that plug into JIRA on the server (which would not require the RESTful endpoint to be accessible).
- For the next phase (Jan-June) it will be important to support people interested in upgrading/migrating to Fedora 4. Nick reported on the Islandora community's plans to spend the first part of the next year developing a path for Islandora users to upgrade to using Fedora 4. Mark Leggott has sent an email to many in the Islandora community in an effort to raise money and developer time for the effort. Nick will lead the effort and Discovery Garden has contributed Danny's development time. David also noted that throughout this process groups of materials will be migrated from Fedora 3 to Fedora 4 and these experiences will be useful as learning opportunities for the Fedora community. David also noted that Hydra folks will be working on full-site Fedora 3 to Fedora 4 migrations during the first part of the next year as well. There was also discussion of what needs the community has with regards to migrations. The NLM brought up handling legacy storage, guidance on whether metadata currently stored in XML should be stored as is or broken out into triples. Documented cases showing the pros and cons of different approaches would be useful to those in the community getting ready to make these decisions for themselves. Andrew noted that these decisions may or may not be generalizable to the point of being able to create general migration tools. There is value in documenting institutions experiences though and perhaps tools, such as a FOXML ingest tool, would be useful. Other things that would be worth seeing best practices for include: what to do with permalinks from Fedora 3 and how to migrate search strategies (for instance GSearch stylesheets) into the Fedora 4 environment. Documenting actual institutions' experience will be very useful. The challenge is engaging institutions to do this and then document their experiences.
- There is a new ModeShape out that seems to address a bug for which the Fedora community has created a workaround. If we upgrade to ModeShape 4.1.0 is our workaround still necessary? Andrew is going to follow up with Esme, who if familiar with the workaround.
- Andrew will be out for the rest of the year (after CNI next week). Should the weekly committer meetings continue or are folks going to be involved with other end of the year wrap-up stuff/vacation time? Several people indicated they'd be around for the rest of the year and Nick volunteered to lead the tech meetings in Andrew's absence. Nick will solicit agenda items on the mailing list and IRC channel and start/stop the weekly calls.