Best Practices for Managing Multiple Teams with GitHub Issues and Projects (V2) #137358
Replies: 1 comment
-
|
🕒 Discussion Activity Reminder 🕒 This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions: 1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as 2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own. 3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution. Note: This dormant notification will only apply to Discussions with the Thank you for helping bring this Discussion to a resolution! 💬 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Select Topic Area
Question
Feature Area
Projects
Body
Hi GitHub Community,
I'm seeking advice on best practices for managing GitHub Issues and Projects (V2) across multiple teams in my organization. Here's the situation:
What I’ve Tried So Far:
Separate Projects for Each Team: Each team has its own GitHub Project, and I created a separate overarching project for tracking features across all repositories. Initially, this seemed like a good approach because:
Challenges Encountered with this setup:
One Unified Project for All Teams: I'm also considering having a single project that all teams use, filtering views by repository or similar. However, this approach raises concerns about scalability and effectiveness for day-to-day operations at the team level. Each team would like their own views I would think...
My Question to the Community:
I'm looking for any advice or experiences you can share that might help us streamline our workflow without creating a monster of a project!
Thanks in advance for your insights.
Guidelines
Beta Was this translation helpful? Give feedback.
All reactions