pattern/innersource-portal-hygiene

[dineshdh]

Inner Source Pattern to help with hygiene of your organisations InnerSource portal

@rrrutledge

[rrrutledge]

This is awesome, @dineshdh! I will try to take a look next week.

[rrrutledge]

I haven't forgotten about this - it just keeps getting moved out. Perhaps someone else in the #innersource-patterns community would be interested in taking a look?

[Ludmila-N]

@dineshdh - "negligence" is spelled with an "i" in the second syllable.
I would also respectfully add that in a corporate setting, I actually haven't seen repos open by mistake or negligence.
Instead, many repos are open for the specific reason of being discoverable. Most of these repos DO NOT automatically adhere to InnerSource patterns/best practices and I agree with the badge idea; but it would be great to mention this as a reason besides "other reasons".
Appreciate you bringing this pattern to life!

[dineshdh]

Thanks @Ludmila-N for your feedback. Fixed the spelling mistake and incorporated your feedback.
I've left the bit about negligence because it actually is a huge problem in my company. People just don't select Private when creating repos for some reason.

[Ludmila-N]

Thanks @Ludmila-N for your feedback. Fixed the spelling mistake and incorporated your feedback.
I've left the bit about negligence because it actually is a huge problem in my company. People just don't select Private when creating repos for some reason.

That's an interesting problem to struggle with, because most of us struggle with the opposite.
Let me ask you (and this may evolve into yet another pattern):
Does your company have clarity on WHICH specific repos should be private, and why?

My company in fact implemented the following to drive the opposite behavior:

1. All repos are created public by default
2. Upon creation you are presented with 3 questions (like: does your repo have trade secrets, does it have a 3rd party vendor code, and one more I forgot); unless you answer YES to one, your repo is created public.
3. This is not implemented yet but has received great leadership support: periodic repo scans that compare private repos to the approved exceptions list, and go after the owners to flip them back to private.
   You COULD do the same in the opposite direction, or you can create the policy (and questionnaire) that allows people to consciously select the right way.
   ====
   Did I miss anything that would warrant private repos?

[dineshdh]

@Ludmila-N my company doesn't really have any solid guidelines on which specific repos should be private, which is no doubt part of the problem. I also work in an enterprise size company and we have thousands of repos, enforcing controls unless automated is near impossible. I think you are right might be a seperate pattern perhaps a general scm-hygiene pattern. This should incorporate things like

• Your suggestion about having some guidelines for what should be private
• Questionnaire whilst creating repos
• Limiting the number of organisation (in a Github context)
• etc ...

[arnom-ms]

First: Thank you for your contribution!
One point I would really like to make here is that InnerSource is a behavior not really a product attribute. I think it is rather confusing to make the distinction with badges as it makes it look that this piece of code is different from another piece of code in any shape or form. In the end however it is not. What may be different is the collaboration behavior and support around that code. Assuming you want the complete transformation of your company to work openly and collaboratively, I would suggest that portals should strive to list all repos/projects in the company (with some sensitive ones excluded of course). For hygiene purposes I would fully agree it s helpful to surface the completeness of the desired artifacts (README etc) in the repo, and you can make the case to favor the ones that exhibit the desired behavior (search result ranking), but I would strongly advise not to curate the resultant list and not to summarize behavior with badges. Essentially excluding repos shrinks the appeal of the portal rather than encourage better behavior (= fixing README etc), badges as summary may not be generally helpful as some collaborators may or may not care about the attributes you score. And last not least curating the resultant list -even just with result ranking - may have as unintended consequences for example that you potentially drive people away from projects that behave the right way but do not meet some formal criteria. There is a delicate line to walk here IMHO. Less is more and a neutral stands of the tooling will help to have confidence in the portal.

[dineshdh]

Thanks for your feedback. I work in an enterprise where our public GitHub repo count in something like 3500 I think. Having all these repos in the portal is not useful imo. So the pattern proposed doesn't actually have any curation as such associated. It merely is a means to ensure only projects intended to be advertised as InnerSource appear in the portal + ensure stale projects are removed if not responded to. I'm happy to elaborate on our company's issues a bit more if you have specific questions

[rrrutledge]

I've seen that idea before - make sure that people and projects need to opt in to be a part of the portal. This step gives some assurance that anyone visiting the portal will have a good experience and find projects that are intended for InnerSource contribution.

Then, again, there may be times with Arno's approach will yield better results. I wonder if this is a case where different Context or Forces are at play and affect which solution is chosen? This aspect is one strength of the pattern format - if we can work together to identify which preconditions would direct the adoption of one approach vs. another then we can codify that in two separate patterns listing out both approaches and when to apply them.

[Ludmila-N]

@dineshdh - another typo on line 24: "Mix of managed and unmanged projects" - assume this was "unmanaged"?

[Ludmila-N]

To add to both @rrrutledge and @arnom-ms comments: I see the possible benefits of creating the portal at the beginning of introduction of InnerSource to the company, as a means to help developers overcome the fear of sharing their code, and to work out as a community what InnerSource/code hygiene standards work for their particular context (aka, integration with company standard deployment pipeline, test frameworks, any automated code review/ linting tools).
However, I am seeing now in my place that said portal can become a hurdle to opening up the InnerSource at scale.
Specifically, I see that
a) many people are confused of what is expected from them, and are focusing their efforts to create a small "showcase" project that can be uploaded to the portal, rather than focusing on a much bigger (and not so shiny) effort of contributing to (or hosting contributions from) other teams/projects
b) many other people feel that they can ONLY contribute to the projects in the portal, which considerably reduces the benefits of reuse/collaboration on their true dependencies
c) leadership sees their projects in the portal as a way to report that "my team is doing InnerSource" whereas wider effort of creating strong README files, establishing automated regression tests and solid code review processes is not viewed as a must-do before you declare "doing InnerSource"

The above reads like I'm opposed to the idea of the portal - but what I want to stress is that it needs to be reviewed/repositioned, and possibly even retired when the company declares their readiness for widespread adoption.
Hope that helps (add fuel to this fire) :)

[rrrutledge]

@Ludmila-N I think that you've done a great job of listing out some of the context/forces where each pattern would apply.

[spier]

Which maturity is this pattern in? I assume Unproven?

Looks like the pattern is rather well defined already, so what would be the next steps to get this merged to master?

[rrrutledge]

what would be the next steps to get this merged to master?

We used to have regular working calls where we could have some synchronous community review and consensus around submitted patterns in case it was difficult to get that asynchronously (via PR). If you're interested in putting some time into it then I think that working group could start up again. Reach out to @NewMexicoKid and he may help a bit with that.

[lenucksi]

This PR has really interesting discussion and a very valid point. This effort here is likely related with candidate generation and ranking: #189

[lenucksi]

We've adopted a new, simpler classification of patterns to enable faster merging to master and hence availability to interested readers and possible continued development and discussion.
Take a look here: https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/meta/contributor-handbook.md

What does everyone think where this patterns would be best positioned at?

[spier]

@dineshdh @Ludmila-N looks like you were the most active in discussing this pattern, hence reaching out to you.

The fork that this PR originally came from seems to be gone, so I am wondering how to best proceed with this idea, so that we don't loose it.

What I am wondering is to what extend this pattern compliments the two patterns InnerSource Portal and Repository Activity Score, as they seem related?

Given that this PR is already open for 1 year, it is at high risk of going stale unfortunately. One proposal that would prevent loosing this content:

We could merge this pattern as Level 1-Initial, as it doesn't seem to be fully fleshed out and doesn't have a Known Instance yet. That way we would capture the content in our repo and give you and others the chance to improve the pattern with further PRs in the future.

What do you think about that approach?

[rrrutledge]

Works for me! I haven't kept totally up-to-date and vested in the methodology of managing the patterns community, so whatever make sense to you seems fine to me.

[spier]

@rrrutledge very understandable. Keeping up-to-date is not super easy yet, as we are trying a new process with these 3 levels (initial / structured / validated), of which we have only been using the first 2 so far.

However a key goal of this new process is to get contributions merged relatively quickly into stage "initial", to make them more easily discoverable by others.

So I think by merging this PR in that state we will achieve that. I will get that done, and then we see how it all plays out.