InnerSourceCommons / InnerSourceCommons/InnerSourcePatterns

InnerSource @ BBC

Đang mở
#511 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

:tiger2: patterns-in-the-wild
Ngôn ngữ chính
HTML
Star
853
Fork
206
Merge trung bình
1 ngày 23 giờ
Pull request đã merge (30 ngày)
2

Mô tả

The BBC is no foreigner to the InnerSource Commons, with some contributions to our patterns already.

This article (03/2022) highlights various collaboration challenges, and how the BBC overcame them. While they don't use the term "InnerSource", it certainly sounds like that model is at play here.

Some ideas for possible pattern connections:

  • technology standardization

    • "Standardising onto a single technology set, building shared ‘horizontal’ capabilities, and sharing commodity components between teams".
    • Their Core Services team was building out the WebCore platform. They were presumably inviting other teams to start using the platform. What experience did they make in enable InnerSource contributions to the WebCore platform itself? And what effect did the technology standardization have here?
    • they also mention Golden path tooling: "used to accelerate teams and keep them within the guardrails of the known-good path"
  • Inversion of Control

    • "When a product development team is used to owning and controlling its entire technology stack, moving to a situation where they are dependent on others can be uncomfortable. However, from operating systems to frameworks, no team writes everything from scratch."
    • "Bringing back the sense of control is important — and this is where maturing the platform to provide tenants with self-service interfaces and tooling is central."
    • making the platform self-service: "This may mean providing tenant teams with controls — configuration, tooling, user interfaces etc. — but it may also mean agreeing and enforcing certain standards."
    • Question: I am not reading enough detail here to actually understand what they mean. Is this about making the WebCore platform as much a self-service offering as say AWS? And why is that called Inversion of Control?
  • Collaboration models between platform and tenant teams

    • the collaboration models between platform teams and tenant teams changed as the WebCore platform was maturing
    • Collaboration => Co-operation/Facilitation => Systemization
    • mentioned in the context of team topologies
    • I think they even call these "collaboration patterns". at least the word "pattern" us used once. not to be confused with our InnerSource patterns in this repo :)
  • allow for "just enough" duplication

    • The answer has been to develop a more pragmatic mindset towards technical debt — developing tools to manage it while accepting that aiming for zero debt is not cost-effective.
    • Just like financial debt, technical debt is not always a bad thing. Debt becomes a problem if it is not tracked, becomes too large or if debtors cannot be held accountable.
    • Question: How to make this trackable in a helpful way?
  • TODO

    • review the "Lessons learned" section one more time.

Note:
Besides extracting patterns from BBC's experience, we could also invite them to one of our Community Calls. With the article above as required reading ;)

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Hướng nghiên cứu

Bắt đầu bằng cách đọc bài viết của BBC được liên kết và so sánh phần thảo luận về WebCore, platform-team, tenant-team và technical debt với các pattern hiện có được liên kết trong issue. Xem lại phần “Lessons learned”, xác định những mối liên hệ giữa các pattern được chứng thực và ghi lại pattern InnerSource thu được hoặc các câu hỏi cần theo dõi; xem lời mời tham gia Community Call được đề xuất là một kết quả riêng biệt.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Đánh giá

Lĩnh vực
content, documentation
Loại issue
Tài liệu
Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức độ hoạt động
Đình trệ
Độ rõ ràng
Cần làm rõ
Mức phù hợp với người mới
20/100

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.