Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs(known-instances): Added SAP to RFC pattern #681

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

dellagustin-sap
Copy link

No description provided.

Copy link

welcome bot commented Apr 11, 2024

Thank You Banner

💖 Thanks for opening this pull request! 💖 The InnerSource Commons community really appreciates your time and effort to contribute to the project. Please make sure you have read our Contributing Guidelines.

If you are submitting a new pattern, the following things will help get your pull request across the finish line! 🏁

  • Confirm that you have used our pattern template. Please remove any placeholder text and sections that your pattern did not need.
  • We run a number of automated checks on your PR. Please review the output of those checks on the PR itself, and see if any issues got flagged that you can fix yourself.
  • Make sure you have added your new pattern to the list of patterns in the main README.md. If you are unsure where to add your pattern, just let us know by commenting on your PR and we will help you.

This project has a small number of maintainers, volunteering their time to this project. So please be patient and we will get back to you as soon as we can. If we don't acknowledge this pull request after 7 days, feel free to chat to us about it in our Slack workspace.

@dellagustin-sap
Copy link
Author

@michael-basil , you asked if SAP could be included as known instance, you may want to review this PR.

@dellagustin-sap
Copy link
Author

dellagustin-sap commented Apr 11, 2024

I recommend to squash this when merging, as I had to send a commit to fix a linter finding.

Copy link
Contributor

@michael-basil michael-basil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great @dellagustin-sap - #sap 😁

@spier spier added 📖 Type - Content Work Working on contents is the main focus of this issue / PR 🐅 patterns-in-the-wild InnerSource patterns that were spotted in the wild. We can extract Known Instances and new patterns. labels Apr 11, 2024
Copy link
Member

@spier spier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this PR @dellagustin-sap. Left a suggestion inline.

Btw, is the CPA that you describe in the blog post similar to an industry body that consists of representatives of different companies to define a standard for the greater benefit of everybody involved? Wondering if the CPA is a similar idea but implemented within a single org.

@@ -98,6 +98,7 @@ Also for decision making outside of pure software design decisions, transparent
- **Uber** - According to this blog post by Gergely Orosz: [Scaling Engineering Teams via RFCs: Writing Things Down][uber].
- **Google Design Docs** - As described in this blog post by Malte Ubl [Design Docs at Google][google]
- **DAZN** (10/2021) - One way that DAZN makes technical decisions is via RFCs. RFCs are used for decisions that apply to engineering-wide processes only! The RFCs live in a GitHub repository, and technical standards are then gradually adopted within their tools and by their engineers. An RFC can be raised by any engineer, and voted on by all engineers. If upvotes exceed downvotes, the RFC is adopted. It’s worth noting, that the RFC voting process hasn’t yet been “stress-tested” by any contentious decisions. - As described in this blog post by Lou Bichard: [Building A DX Team: Lessons Learned][dazn]
- **SAP** - As described in the blog post [Cross-Product Architecture: Embracing Conway's Law for Better Software Architecture][sap-cpa], SAP has a mature tool-assisted process for document review across teams. It is primarily used for the review of Architecture Decision Records (ADR) originating from cross-team work done on the Cross-Product Architecture collaboration model. This means that the review process in not easily available for decisions on small projects. Also, the documents are not by rule related to InnerSource projects. That means it is not a universal solution for engineering decision making in the company and also not a 1:1 fit for this pattern, but close enough to be mentioned as known instance.
Copy link
Member

@spier spier Apr 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- **SAP** - As described in the blog post [Cross-Product Architecture: Embracing Conway's Law for Better Software Architecture][sap-cpa], SAP has a mature tool-assisted process for document review across teams. It is primarily used for the review of Architecture Decision Records (ADR) originating from cross-team work done on the Cross-Product Architecture collaboration model. This means that the review process in not easily available for decisions on small projects. Also, the documents are not by rule related to InnerSource projects. That means it is not a universal solution for engineering decision making in the company and also not a 1:1 fit for this pattern, but close enough to be mentioned as known instance.
- **SAP** (03/2024) - SAP has a mature tool-assisted process for document review across teams. It is primarily used for the review of Architecture Decision Records (ADR) originating from cross-team work done on the Cross-Product Architecture collaboration model. Some noteworthy implementation differences from this pattern: The review process is not easily available for decisions on small projects. Also, the documents are not restricted to InnerSource projects only. - As described in the blog post [Cross-Product Architecture: Embracing Conway's Law for Better Software Architecture][sap-cpa].

Proposing a number of changes. In summary:

  • moving the link to the end
  • adding a date of when we found this known instance (i.e. when you shared it). we don't do this consistently for all Known instances in all patterns yet but it may help us in the future when we try to learn how pattern adoption is spreading through different orgs.
  • Removing the qualifying sentence at the end. The pattern does not claim to be a universal solution for all engineering decisions. Further all implementations of this pattern (and any pattern for that matter) have some differences to the solution outlined in the pattern. That is to be expected, as the solution has to be adapted to the specific environment at the given organization. We have not highlighted this in other Known Instances either, therefore we don't have to do it here either.

Hope my explanations help and you like the changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
📖 Type - Content Work Working on contents is the main focus of this issue / PR 🐅 patterns-in-the-wild InnerSource patterns that were spotted in the wild. We can extract Known Instances and new patterns.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants