Firefly Contribution Process

Firefly Contribution Process

Step 1: Intake

  • All new Firefly feature requests must go through a JIRA intake process. This is a required step for the following reasons: 1/ Accessing the Firefly GitHub repo 2/ Adding new GraphQL schema 3/ Updating model or resolver or Dao’s. 4/ Infrastructure changes. For customer issues that need urgent attention create t.corp ticket.

  • Create intake story using the JIRA template here and fill out all the fields (including Goal alignment, expected delivery date, any design doc, what alternatives have been explored etc., )

  • JIRA is the authoritative source of truth for Firefly projects. The DevEx API team will use the JIRA ticket to track progress and keep stakeholders informed of whether an intake is accepted and the timelines.

Step 2: Prioritization

  • The Firefly intake requests are reviewed on a bi-weekly basis. During this review, Firefly Product will assess whether the requested feature aligns with the FireFly product vision and roadmap and thus should be included as part of FireFly. In case the feature doesn’t align with FireFly’s vision, communication would be updated on the intake JIRA with the decision. Although, not mandatory FireFly would also propose alternate solutions outside of FF that can be explored by the requesting team.

  • For requests that are aligned with the FF vision and Roadmap, Firefly Product will communicate on the ticket about the same and also provide the details if the request would be served by the core FireFly team or by the requesting team working with the FireFly team using the contribution model.

  • For requests accepted to be delivered using the contribution model, relevant acceptance criteria would be added to the intake JIRA to evaluate the successful completion of the task. Further, the launch quarter in the JIRA reflects the time when an Firefly team would be able to work on this request and the Firefly on-boarding buddy is set in the Owners field of JIRA.

Step 3: Execution Phase for approved intakes

For requests accepted to be delivered using the contribution model, the following process is followed:

  • We will work with the team requesting the feature to identify specific resources (engineers, designers, etc.) who will need access to the Firefly codebase. The identified developer would be added to firefly development slack channels, teams etc. so they have access to these forums to get their questions answered and be part of the team.

  • The identified resources, including the Software Development Engineers (SDEs), will be required to attend the regular DevEx API team standups. The SDE will be provided with an onboarding buddy who will guide them on the process and setups. This ensures they have the same access to information and resources as the core Firefly team members, allowing them to work seamlessly as a single team to deliver the feature. The access provided will have a defined end date, after which the team’s involvement in the Firefly will be re-evaluated and updated as needed.

  • We strongly recommend that the SDEs assigned to work on the Firefly feature must complete the following training courses before being granted access to the Firefly GitHub repository. This training requirement ensures the SDEs are proficient in the GraphQL and TypeScript technologies used in the Firefly codebase.

  • In addition to the training, the SDEs will also review previous Firefly schema designs [1][2] to familiarize themselves with the existing codebase and development process. This will enable them to come up with their own schema design proposal in a format that can be easily reviewed and approved by the Firefly maintainers and community. NOTE: Firefly maintainers are independent bar raisers and come from various teams within MCX.

Step 4: Design Phase

  • Once the developer has on boarded they would use the template FF Schema Proposal Template to detail the 1/ background information, 2/ requirements and 3/ Design for their feature.

  • Based on the discussions and information gathered during the design process, the engineer will complete the remainder of the FF Schema Proposal document with a proposal that satisfies the requirements. The goal is to put forward a comprehensive schema proposal that satisfies all the identified requirements.

Step 5: Design Review

  • The SDE responsible for the feature would organize a schema review meeting with the Firefly Maintainers and the Firefly Product Manager.

  • Maintainers will identify any open questions and provide feedback on the schema proposal, leaving either a Feedback Provided or Approved status in the Approval table at the bottom of the FF Schema Proposal document.

  • If the schema proposal does not receive approval, the SDE will need to address the feedback and revise the proposal accordingly.

  • Once the schema proposal has been approved by the Firefly Maintainers can the process advance to Step 5.

Step 6: Development Phase

  • After the schema proposal has been approved by the Firefly Maintainers, the requesting developer will proceed to implement the approved schema. The developer would use the standup’s post scrum session to get answers to any clarifying questions they may have.

  • Callout: The initial code changes should only modify the Model and Resolver files, and should not touch the DAO or Transformer files.

  • Once the schema change code is complete, a Merge Request should be created in GitLab. This will initiate the final review and merge process for the schema changes.

Step 7: Merge Request Review

  • Firefly Maintainers and DevEx API team will review the Merge Request and provide feedback or approval. There won’t be dedicated maintainer review or office hour session with this new streamlined extended team contribution process.

  • Once the MR is approved, the code will auto merge in the next available window.

Step 8: Intake closure

  • This process continues until the feature is complete and acceptance criteria set in met. On completion, the engineers’ access to the Firefly git repo will be removed, and they will no longer need to attend the Firefly standup’s. The relevant intake will be marked as closed.

  • Future issues or extending the schema follows the same process (starts from Step 1) outlined in this firefly contribution model.

  • If there are issues after the feature is in production use tickets rather than JIRA intake (except for schema changes or additions).

Revision History

Version

Date

Changes

Author

v1.0

3/4/2024

Original document

alewehn

v2.0

4/12/2024

Updated contribution/review process

senkan

v2.1

8/5/2024

Updated document formatting. Included links to ticket and schema design templates

bgeck

v2.2

9/19/2024

away team engagement model

senkan

v3.0

3/7/2025

Updated contribution model, prioritization framework tenet, context and purpose

senkan