Joining the Open Data, Design, and Development (ODDD) project team - DOI-ONRR/nrrd GitHub Wiki
Getting set up
Follow the instructions in the onboarding checklist to create an issue that will guide you through tasks that will lead you through the product orientation and get you up to speed and contributing in no time. Track your progress by checking the boxes as you complete tasks.
Products we maintain
Natural Resources Revenue Data website
This site provides open data about natural resource management on federal lands and waters in the United States, including oil, gas, coal, and other extractive industries.
Office of Natural Resources Revenue website
This site is the public, front-facing site for the Office of Natural Resources Revenue (ONRR). ONRR collects, accounts for, and verifies energy and mineral revenues. We then distribute the funds to States, American Indians, and the U.S. Treasury. The onrr.gov wiki and repo contains more information about our work.
Open Data, Design, and Development blog
This site is our team's blog. We share thoughts about our current learnings and projects here. The blog wiki and repo contains more information about our work.
Project team
| Role | Responsibilities | Currently Filled By |
|---|---|---|
| Product Owner | Defines the product vision and makes sure what we’re working on carries out that vision. | Maroya Faied |
| Developer | Writes the code, develops the technical strategy, and decides on technical tool sets. | Jeff Schwartz |
| UX Designer | Conducts user research to understand user needs and designs the site to meet those needs. | Erin Elzi and Alexandra McNally |
| Program Analyst | Makes sure we have current and accurate data and interfaces with other groups within ONRR. | Lindsay Goldstein |
| Content Strategist | Develops strategy for and maintains all content on the site. | Christine Thomas |
Meetings
Our team works in Agile, which is a development framework that encourages:
- iterative development
- disciplined project management
- frequent inspection and adaptation
- teamwork, self-organization, and accountability
- rapid delivery of high-quality product
- a business approach that aligns development with customer needs and company goals
The table below outlines the regular cadence of sprint activities. Each meeting has a video call link in the calendar event. The product manager will invite you to each.
| Meeting | Description | Regularity | Duration |
|---|---|---|---|
| Sprint planning | At sprint planning meetings, the tasks that the team agrees they can complete over the course of the sprint are prioritized and assigned for completion. | First Monday of each new sprint | 1 hour |
| Sprint demo | Sprint demos allow the team to present work that was completed in the sprint to other team members and stakeholders. They also create opportunities to others to ask clarifying questions. | Second Thursday of each sprint | 1 hour |
| Sprint retro | Retrospectives allow the team to reflect on the sprint that just finished and discuss what's working and what's not. This allows the team to identify areas to improve. | Second Thursday of each sprint | 30 minutes |
| Standup | Daily standup meetings allow team members to share progress on assigned tasks and surface any blockers to their work. | Every day except the first Monday of the sprint and the second Thursday of each sprint (the days with sprint planning and demo/retro meetings) | 30 minutes or less |
| Roadmapping | Roadmap check in meetings allow the team to plan work spanning several sprints. | Every 6 weeks | 60 minutes |
| Backlog grooming | During backlog grooming, the team goes through open issues to close duplicate or unnecessary issues and to assign remaining issues. | Monthly | 60 minutes |
Our 2-week sprints (DevOps)
- Each 2-week sprint includes: daily standups, weekly synch up, bi-weekly sprint planning, bi-weekly sprint review/retro, and bi-weekly sprint demo.
- We decide what individuals are working on at the beginning of each sprint. We define sprint goals based on previous velocity estimates.
- Everything goes into the two-weeks sprints. This includes user research, design, content strategy, development, analysis, and quality reviews.
Long-term planning (DevOps, product management)
- Epics are every 6 weeks. We plan epics in a road mapping session (one-hour meeting) at the beginning of the epic to decide what goes into the epic.
- We refine the backlog once a month. We remove old issues and prioritize and estimate ones we want to keep.
- We conduct ad hoc design studios, as needed, to shape solutions for larger projects. Ad hoc design studios occur when there is a request for a new product or we see an area to improve upon. Design studios usually include group brainstorming, individual prototyping, sharing and hole-poking of prototypes, and coming to a decision on a prototype. User testing and user research can also be involved.
