-
Notifications
You must be signed in to change notification settings - Fork 46
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
Feedback to PR #481 - Introduction - Is InnerSource Right for My Project #489
Comments
Thanks, @dellagustin-sap ❗ I feel like your could be its own article - called something like "InnerSource Everywhere!" That article can advocate for running everything as InnerSource without any qualification. |
I think it's OK for different articles to contradict one another as long as each is focused, clear, and consistent on its own. Then people can mix and match out of our cadre of articles with InnerSource advice. |
Maybe over time we can come up with different tags to help people navigate and find which articles are useful to them based on attributes and surrounding context or culture or goals that is present in their business environment. |
Hello @rrrutledge , one aspect of my feedback - I did not take the context of where the text would be into consideration - I tried to find back then where it was published, but could not find in the website - where is this article published? That can help me understand it better - I like the idea this "InnerSource Everywhere!" article. |
In that regard of a structure: I think the Mindmap concept Feiwan contributed to the patterns WG might possibly be worth considering here too. |
@dellagustin-sap it isn't published, yet, but we'll plan to have it as a companion to these articles: https://innersourcecommons.org/learn/learning-path/introduction/ Would you be interested in working on an "InnerSource Everywhere!" article? |
I'm interested, are there any deadlines or can I do it on my pace? |
No deadlines! I created the issue InnerSource Everywhere! Article to track and sent you an invite to join the project. |
@rrrutledge great, thanks, could you please also add my other GitHub user, @dellagustin? I use two separate users so that I can have a clear separation between on-the-job contributions and spare time contributions. |
With that, I'll close this issue, as from my point of view the topic will be followed up on #494. |
Sounds great - thank you! |
Closing this as future work will be tracked in #494. Thank you for sharing your ideas @dellagustin-sap! Looking forward to seeing the new content. |
Hello, I'd like to leave some feedback for #481.
I often advocate that an InnerSource approach makes sense even if the maintainers of a project do not expect contributions, as adopting InnerSource practices have other positive side-effects/byproducts, besides contributions (specially when speaking of code contributions):
Also, I like to promote the idea of "Agile InnerSource Adoption" (just created the name) - in other words, adopting InnerSource is done in small value-adding steps that are tracked as part of the project backlog (i.e., document onboarding steps, document development processes, open up backlog, adopt, start accepting contributions from the outward in - e.g. docu first, then client libs, then service, etc...).
With that in mind, I think InnerSource is only not suitable for confidential projects. Even then there are ways of adopting some of the practices (referring here to the CLOSED and RESTRICTED repos on the Balancing Opennes and Security pattern).
All the rest is pretty good.
The text was updated successfully, but these errors were encountered: