如果您在组织中，可能会有私人的GitHub存储库（即您无法访问它们），但是知道它们存在很有用，然后您可以在适当的地方安排访问权限。
换句话说，我们正在尝试以一种可以导致访问的方式启用可发现性。这可以通过共享Readme的作品来完成（指出人们需要有一些纪律来撰写明智的读书文件）。
这篇博客文章解决InnerSource Disclionability问题就像潜在的解决方案一样，但可能要求用户可以访问该门户中的所有存储库？我希望用户能够为所有存储库查看README的内容 - 如果他们无法访问，则可以联系在读书中列出的任何人。
我看到了另一个可以从私人仓库中公开文件的选项（使用GiteXporter仅使用readme创建一个公共回购， >这是公开的，而不是我的第一个偏好，并且每个回购都不是理想的。 =
提出了一个相关的，也许更简单的选项在这里，学生再次从私人仓库中共享一个私人仓库的读书我，需要每个仓库中的少量工作，没有整洁的门户，但是可以通过github搜索找到？ 可以将公共github页面私有化，但是只能对储存率访问的人可见
虽然
- ？可以通过组织中的某人进行搜索（最好不是每个人修改其存储库）来访问这一点。
具有功能的其他功能：
- 可以在门户网站上查看所有注册，并以搜索
- 奖金能够制作超级私人（只有合作者才能看到readme -indme in readme中的flag？），org private（只有在org-默认值）和public（readme中的标志？）。
- 简单实现！
建议？
If you are in an organisation, there may be GitHub repositories that are private (i.e. you don't have access to them), but it would be useful to know that they exist, and then you could arrange access where appropriate.
In other words we are trying to enable discoverability, in a way that can lead to access. This could be done with sharing readme's (noting that people need to have some discipline to write sensible readme's).
This blog post Solving the innersource discoverability problem looks like a potential solution, but may require that the user has access to see all the repos in the portal? I'd like for the user to be able to view readme's for all repos - if they don't have access, the can contact whoever is listed on the readme.
I see another option for making a file public from a private repo (using gitexporter to create a public repo with only the readme, example here. This makes it public, not my first preference, and would require every repo to do some work, far from ideal. While it doesn't give a neat portal, it should allow GitHub search functionality to find it by topic or keyword?
A related, perhaps simpler option is proposed here, where a student shares a readme from a private repo as a public GitHub page. Again, requires a little work from every repo, no neat portal, but can be found with GitHub search? While public Github pages can be made private, then would only be visible to those with repo access?
So, if I'm summarising basic requirements:
- All org repos (public, private or team) have a readme that can be accessed by search by someone in the org (preferably not requiring each individual to modify their repo).
Additional nice to have features:
- All readmes can be viewed in a portal with search
- Bonus for being able to make super private (only collaborators can see readme - flag in readme?), org private (only people in the org - default) and public (flag in readme?).
- Simple to implement!
Suggestions?
发布评论
评论（2）
我认为您已经为此此处提供了合适的解决方案< /a> 已经在你的问题中了。或者，您可以使用 API (GET repos， 获取自述文件repo) 获取每个存储库 README 并将其保存到基于 cron 调度程序的数据库/JSON 中，并根据该数据创建一个 Web 界面。
但是，我将详细说明一些需要改进的地方。我看到的问题是搜索的本质。我们并不总是在寻找关键字，有时我们会尝试为我们的问题找到潜在的模糊匹配，特别是在拥有数千个存储库的大型组织的情况下。在这些情况下，搜索引擎实施将提供更好的结果。在我看来，我们应该收集README和FAQ并将它们放入Elasticsearch中，公开搜索API以供查询。自述文件和常见问题解答的集合应该是 CI/CD 管道的一部分，并且在将新版本推送到工件时，它还必须发布元数据。
I think you have already provided a suitable solution for it here already within your question. Alternatively, you can use APIs (GET repos, GET README of a repo) to get each repositories README and save it to a database/JSON based on a cron scheduler and create a web interface based on that data.
But, I'm gonna elaborate on a few areas of improvement. The problem I see with this is the nature of the search. We aren't always looking for keywords, sometimes we are trying to find a potential fuzzy match for our problem, especially in the case of a larger organization with more than a couple of thousand repositories. In those cases, a search engine implementation will provide much better results. In my opinion, we should collect the README and FAQs and put them into Elastic search, expose search API for queries. The collection of README and FAQs should be part of the CI/CD pipeline, and while pushing new versions to artifactory it must publish metadata as well.
对我来说，这看起来像是内部存储库的一个用例。您可以找到有关内部存储库的更多信息
您是否可以使用内部存储库很大程度上取决于您公司的政策。
另一件需要考虑的事情是，这将公开您的整个存储库，而不仅仅是自述文件。
This looks like a use case for internal repositories to me. You can find more about internal repositories here.
Whether you can use internal repositories or not highly depends on your company's policies.
Another thing to consider is that this will expose your whole repositories, not just the README.