Extended Team Contribution Model

Extended Team Contribution Model

Firefly intakes that have been prioritized by the Firefly product team and approved for extended team contribution will follow the newly revamped contribution model. In this model, the contributing developer will be fully integrated into the Firefly team, actively participating in sprint ceremonies such as sprint planning, scrum meetings, standups, and demos. They will collaborate with the Firefly team to complete deliverables as outlined in the Firefly Contribution Process.

To support their onboarding, an onboarding buddy will be assigned to assist with any issues. The developer will also be granted access to the Firefly code repository for the duration of the project, with permissions similar to those of a Firefly team member.

 

FAQs

Q: Why is the Firefly team implementing this new contribution model?
A: The new contribution model ensures that extended team developers are fully integrated into the Firefly team. It fosters better collaboration, improves code quality, and encourages alignment with Firefly’s development processes.

Q: Will this model slow down development?
A: No, it is designed to increase efficiency by reducing back-and-forth communication, minimizing rework, and ensuring early alignment between teams.

Q: Why is it important for contributing teams to attend the Firefly sprint planning, standups and demo’s? A: Attending standups enables contributing teams to stay aligned and collaborate effectively with the core Firefly team. It ensures they have equal access to information, resources, and project visibility. Under the new contribution model, participation in standups and sprint ceremonies is mandatory.

Q: What are the standup, sprint, and demo times for Firefly team?
A: Firefly Standup is at 11:30 AM PST. Sprint planning occurs bi-weekly on Tuesdays at 2:00 PM PST, and demo day is every Monday at 11:30 AM PST. There is no standup or meetings on Music’s no-meeting days (Wednesdays).

Q: How are schema reviews done?
A: Schema reviews will be schedule after the associated intake has been approved. Please reach out to senkan@ for the schema review schedule.

Q: I’m in a different timezone and cannot attend standup or sprint ceremonies at the scheduled time. What should I do?
A: Attending standup and sprint ceremonies is mandatory to receive necessary support, otherwise it could lead to delays. If you’re in a different time zone, we recommend finding alternative solutions—such as partnering with a team member in a compatible time zone who can attend on your behalf. Additionally, please work with your own leadership or the Firefly leadership to explore options that enable your participation in Firefly sprint ceremonies.

Q: How do we handle work which arises mid-sprint that are related to Firefly?
A: If work arises mid sprint, contributing developer will create the JIRA and pull it into the Firefly sprint board. Contributing developer will attend the FF standup while actively working on the task.

Q: What happens if I cannot attend standup due to conflict, oncall etc.,
A: We understand scheduling conflicts can arise. In those cases, please post a brief update on the relevant Slack channel (#firefly-api-dev) so the team is informed of your progress.

Q: Our project got de-prioritized do I need to attend the standup? A: Not required. If your project is de-prioritized, your access to the Firefly codebase will be removed, and you can stop attending standups. You should also remove all the code added into Firefly code base before closing the JIRA. However, please provide an explanation for the de-prioritization so we can understand the context.

Q: I’m in a different time zone - how can I connect with the Firefly maintainers?
A: We strongly recommend presenting your schema proposal directly to the maintainers, as this allows you to walk through your design choices and receive their feedback. You can coordinate with the Firefly maintainers to find a suitable time for the discussion.

Q: What if I disagree with the maintainers on the proposed schema design?
A: The Firefly maintainers are responsible for upholding the quality and consistency of the overall Music GraphQL schema. If you have a strong rationale for your proposed schema design, you should work collaboratively with the maintainers to understand their concerns and see if a compromise solution can be reached. The key is to maintain a collaborative, problem-solving mindset. The Firefly maintainers are responsible for the overall schema quality, but they would be willing to consider well-reasoned alternative proposals from contributing teams.

Q: I got approval from the maintainers, but there was a difference of opinion during the merge request review. What should I do?
A: If there is a difference of opinion that arises during the merge request review, even after the schema proposal was approved by the maintainers, the team should use Amazon’s “two-way door” decision-making approach. Be prepared to provide additional data or rationale to support your position. The goal should be to find the best outcome for the Music GraphQL schema, even if it means adjusting the original approved schema design.

Q: I completed the development but didn’t complete the acceptance criteria listed in the JIRA. Is that ok? A: No, the intake is only considered complete once the acceptance criteria listed in the JIRA ticket has been fully met, regardless of whether the development work is finished.

Q: I completed the code and submitted a merge request. Who will review and approve it?
A: First, have your merge request reviewed and approved by your onboarding buddy and other FF team members. Merge requests that haven’t received all required approvals (or not merged) can be brought to the regular review sessions held every Tuesday and Thursday at 3:00 PM. Sign up sheet.

Q: What happens if my merge request gets stuck in the review process?
A: If your merge request gets stuck in the review process, you should bring this up during the Firefly team standup. This will allow the team to collaborate on finding a solution to unblock the review. The key is to use the collaborative nature of the standup to surface any merge request review issues and work as a team to find efficient solutions. By proactively communicating the problem, the team can ensure your contribution doesn’t get held up unnecessarily in the review pipeline.

Q: Will I be a reviewer for Firefly merge requests?
A: Yes, contributing developers will be added as reviewers for Firefly merge requests. There is no distinction between core Firefly team members and contributing developers in this process. However, once the engagement ends, you will be removed from the approver list.

Q: What is the best option to get questions answered related to Firefly?
A: We recommend using sage forum to get any questions answered about Firefly. The Sage forum is used as a centralized knowledge base for all Firefly-related questions and discussions. It will serve as the primary channel for the community to get their questions addressed, rather than the existing Firefly-interest Slack channel.

Q: What about Firefly Office Hours, do I need to attend?
A: Firefly Office Hours was intended for teams looking to consume Firefly, not contribute to Firefly. With the updated Firefly contribution model provides developers with all the necessary access and collaboration opportunities to get their questions answered, without the need for a dedicated office hour. The team can focus on delivering the work efficiently rather than coordinating separate office hour sessions.

Q: Can I forward the standup invite to my manager or add them to firefly-api-dev slack channels?
A: No, The only exceptions are the Firefly SDM and the Firefly Product Manager. They are part of the standup meetings to help unblock teams and provide product-level guidance when needed. But in general, we want to keep the standup as a developer-to-developer forum, without adding additional stakeholders. The contributing developers should be the primary point of contact for their managers regarding Firefly-related work.
     

Reference:

      Recommended Training:

      Revision History

Version

Date

Changes

Author

v1.0

3/18/2025

Original document

senkan

v1.1

4/30/2025

updated with MR/Schema review

senkan

<img src=”https://beta.api.watchlight.music.amazon.dev/pixel.gif?apiKey=wl_prod_zPJp1Iofl2mgf44VRYhoLqSN&trackerId=9e8d90a5-eb0f-487c-bcc1-6548fe457ff9” loading=”eager” style={{position: ‘absolute’, left: ‘-9999px’}} width=”1” height=”1” alt=”” />