The FOLIO software development site is available at dev.folio.org.
FOLIO uses discuss.folio.org for asynchronous messaging. The Discuss site is a web forum with categories, topics, and posts. Use Discuss for asking questions and recording discussions that require more than a few sentences.
FOLIO uses wiki.folio.org to store documents with some permanence. FOLIO Special Interest Groups (SIGs), which are dedicated to specific functional areas or interests within FOLIO, have a space on the wiki.
Join the SIG meeting that is appropriate to the area where you are working: Community Calendars
Sign up for SIG mailing lists so you get all the emails sent to the group(s): https://ole-lists.openlibraryfoundation.org/
The FOLIO Google Drive has working documents for various project groups including most SIGs and the Product Council.
For Product Owners working with the Core Team:
There is a Monday roundup meeting at the start of each sprint, 9:30-10:30 US ET, where POs present any new stories to the developers. For access to the coreteam calendar, which includes the sprint and roundup web conference information, please contact Cate Boerema.
Please include any mockups for your app in the shared Google UX folder, in a subfolder for your particular app. For access to the UX folder, contact Cate Boerema.
Product Owner Meetings:
JIRA (list of projects): https://issues.folio.org/secure/BrowseProjects.jspa?selectedCategory=all
User stories have the following general format:
- Purpose - Story context for casual viewers. What is this story supposed to cover? If it's just an initial iteration of a larger feature, make that clear here.
- User story statement(s) - The user story statement is optional and you'll notice that many of our stories don't contain them. This is because, between the purpose and the scenarios, there is usually more than enough information to go on. That said, including a user story statement is best practice and if you have them please include them. They will take the format: As a < type of user >, I want < some goal > so that < some reason >
- Scenarios - On FOLIO, acceptance criteria are written as scenarios using the "gherkin syntax" (given, when, then)
- Attachments/links - Whenever possible, a UX mockup should be attached or linked to the user story. If there are elements of the mockup that are out of scope for the story (for example, because the technical prerequisites are not in place), then they should be noted as "out of scope for this story"
Some example user stories:
- UIU-253 - Loan Actions: Loan Action for Requests
- UIREQ-1 - Requests: View Request Details v1
- UIU-181 - Assign Proxy v2: Sponsor Sub-Section
Epics and features
Higher level work is defined in epics and features in a JIRA project called UXPROD.
- You can view a filterable list of epics in UXPROD here.
- To enable tracking against the line items from the v1 roadmap spreadsheet, our initial set of epics were created by importing those roadmap items. NOTE: As of 2018-05-31, we are converting the v1 line items into UXPROD "umbrellas" so we can create more project-oriented epics for organizing our work.
- If you’re creating epics from scratch, it would be useful if you could scope them like mini projects that could be independently prioritized or handed off to another development team (not that this will happen – but it’s a useful lens for viewing boundaries).
- You can find a filterable list of features in UXPROD here.
- POs decompose epics into features based on their conversations with the SIGs. The idea is to capture larger work increments with as much unstructured description as is available. A well-scoped feature is something that is relatively self-contained so it can be prioritized independently. It should also be something that is “whole” enough to provide value on its own. So, “Manual License CRUD” might be a good feature while “View License Record” or “Validate License Data” would be stories. Stories should be linked to features as "related issues"
- POs are responsible for moving these through the Kanban board.
- To Do: Features for which conversations have not yet begun with the SIGs
- Analysis: Features for which discussions with the SIG are underway
- Analysis Complete: Features for which the user stories and mockups are generally completed. Of course, features are rarely ever really complete. One will often need to revisit designs, data and business logic over time. But when the PO feels the work is mostly done, the feature can be moved to Analysis Complete.
- Dev Complete: Features for which all development work has been completed
- Why no "Dev In Progress" status? Because the features are large enough that very often initial development will have started before analysis has completed. The focus of UXPROD is more on the status of the features in analysis than on the development itself. Development is managed and tracked primarily through user stories.
- How UXPROD feature statuses map to the Feature Kanban statuses:
- Example features:
- Feature estimates:
- When features are created, you should ask for them to be estimated (front-end estimate and back-end estimate)
- This will allow us to stay on top of our project plans and help SMEs make informed tradeoffs regarding what should be prioritized
- For POs working with the Core team, Jakub has put together a list of developers you should contact for estimates by area.
For who is working on what, please see the Directory of Product Owners by Area of Focus.
Questions about the Product Owner role or processes? Contact Cate Boerema