You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* If only X knew what X knew; the internal search engine is bad. No one can find anything because it is difficult to add things to the search index.
18
+
* We have similar challenges getting data sources pulled into the search engine. PayPal is building a project called Agora to do this and they are planning to open source it.
19
+
* Github Enterprise and npmjs have built-in searches on meta-data. Enterprise that opts into these tooling will get some of that functi
20
+
* Software component(s) are available internally but users can't easily find these.
9
21
* This problem is more likely to occur where there are silos in the company (e.g., larger companies; smaller companies may have fewer opportunities for reuse of internally developed software).
10
22
* The company traditionally has been bad at sharing across silos (people don't have the culture of sharing).
11
23
@@ -25,11 +37,13 @@ People don't bother looking for internally developed solutions - they might not
25
37
## Solution
26
38
Make it easy to find the reusable code.
27
39
28
-
* Pull in Repo names, descriptions and README.md files into the search engine
29
-
* Implement process change to first check for internal solutions for this problem
40
+
* Pull in Repo names, descriptions and README.md files into the search engine assuming that a search engine exists. Note: a one-stop-shop kind of search engine for all relevant communication and documentation is difficult to attain. Even when using Github's enterprise offering, people often deploy additional systems like wikis to host content orthogonal to what is in the code repositories, slack channels (or IRC), mailing lists (or even nntp servers), some place to store stuff written down in office formats, search over personal e-mail etc. Several of these systems come with search built-in, but integrating this content in one search box or even just deploying a federated search engine across all sources often doesn't come off-the-shelf.
41
+
* Implement process change to first check for internal solutions for this problem.
30
42
* Tool with a central view (but people are more inclined to google externally than look internally)
31
43
* Concierge service (guide) to help product people find stuff. Might not scale but could be helpful in the beginning.
32
44
* Need some very visible lighthouse projects that start using inner source components and make positive statements about the inner source program.
45
+
* Establish a common, asynchronous communication channel (e.g., like slack or metamorph or yammer) across team boundaries. This might not scale beyond a certain organisation size. It is possible people will start splitting this one channel into multiple channels by topic once traffic gets too high. Note: having one channel for many users of one tool might be considered an anti-pattern because they can't find it unless they already know about it.
46
+
* PLACEHOLDER FOR RUSS
33
47
34
48
## Known instances
35
49
@@ -38,6 +52,7 @@ Make it easy to find the reusable code.
38
52
* Developers looking for code can search for it and find it quickly.
39
53
* Developers are now looking internally for software components
40
54
* Search results are combined (internal and external)
55
+
* See [Improved Findability](https://github.com/paypal/InnerSourcePatterns/blob/master/poor-naming-conventions.md) (aka Poor Naming Conventions or Badly Named Piles) as a related pattern.
0 commit comments