Closed LaureenH closed 4 years ago
:tada: thanks!! We had some back and forth on the language around:
"Search the most starred Android repositories on GitHub. Explore with search examples below." to "Use these search suggestions to explore popular Android repositories on GitHub."
I suggested "starred" because if we only say "popular" it's not clear what that means (what's the measure for 'popular'?). In the context of a typical GH user reading this, 'stars' is immediately obvious what we mean and correlates with popularity. To be more precise we could say "popular Android repositories by GitHub stars" or "popular Android repositories (by stars) on GH" but that feels long.
Agree with @rvantonder, there's often a lot of code that isn't really popular, that's an important concern for developers. GitHub has multiple ways it measures popularity like stars or “Trending” or “Topics”. Besides stars, the other ways popularity is measured is often not reliable or inaccurate.
For these pages, some pages have only top starred repos and for others it’s a mix of top starred repos and top starred repos in "Trending" (that’s why some descriptions say “trending and most starred”) @LaureenH how would you suggest best capturing this here?
here's why I don't like the "starred" term -- it's because it doesn't necessarily mean anything either: https://opensource.stackexchange.com/questions/5110/github-stars-is-a-very-useful-metric-but-for-what. I genuinely don't want to get in the habit of trading one ambiguous term for another, and stars may be a measure of popularity but they may also just be someone's bookmark, in which case, "popular" is a better term for what we're trying to imply on the page, which is that repos with a lot of traffic are included in these searches we're trying to show people how to do.
I don't have the context to know for sure which option is the more technically correct; if we're literally sorting repos by stars, then "starred" is correct, but we shouldn't use that with "popular", because "star" doesn't necessarily mean that. Does that make sense?
on all pages, please render code terms in code font
The current implementation does not let us render in this way. I think it's a fairly straightforward fix to change the page title and the search titles to take an element or to handle markdown rendering, it's just out of scope of a change I can make.
I'm not happy with the "Search a language" section. If the languages listed are the search terms, they should be all lowercase. If they're the names of the languages, they need to be properly capitalized (JavaScript, GraphQL, HTML, JSON, TypeScript)
It doesn't appear that we have proper formatting of the names of the languages easily available to us in the code here, so I made the decision to use the search term and lowercase them all. This feels consistent with the monospace font styling they have. @LaureenH - are you happy with this as a solution? Here's what it looks like:
@christinaforney totally happy with that. =) Thank you so much! Is code render a thing we're going to have on a roadmap at some point?
Is code render a thing we're going to have on a roadmap at some point?
This is just a hard coded implementation to quickly validate the idea, so we will definitely be iterating on this. I will make sure that rendering code is part of the next iteration requirements!
[x] on all pages, please remove the colons from all headers
[ ] on all pages, please render code terms in code font
https://sourcegraph.com/search
[x] ~remove the colon from the end of "Diff/commit search keywords:"~ (already fixed)
[x] ~Change "Structural Searches" to "Structural searches"~ (already fixed)
[x] I'm not happy with the "Search a language" section. If the languages listed are the search terms, they should be all lowercase. If they're the names of the languages, they need to be properly capitalized (JavaScript, GraphQL, HTML, JSON, TypeScript)
https://sourcegraph.com/refactor-python2-to-3
[x] change the main header to read: The examples below help you find Python 2 code that requires refactoring, and review examples of the new Python 3 syntax, across popular Python repositories.
[x] change the "Python 3 explicit relative imports paragraph to Python 3 requires you to explicitly specify package location relative to the current folder, and deprecates implicit relative reports. The search below returns usages of explicit relative imports. For example, an import with one leading dot signifies that the package resides in the current folder, and with two leading dots tells Python that the package is one directory up from the current one.
[x] Change "Python 2 & 3 integer conversion:" to "Python 2 and 3 integer conversion"
https://sourcegraph.com/react-hooks
[x] Change "Search popular React Hook repositories from resources in the GitHub repository 'rehooks/awesome-react-hooks'. The search examples show usages of the React Hook useState with various data types. useState is a hook that lets you add React state to function components." to "Search popular React Hook repositories from the GitHub repository 'rehooks/awesome-react-hooks'. The search examples show usage of the React Hook
useState
with various data types."[x] please change "Javascript" to "JavaScript" in both places it appears on the page
[x] please change "Typescript" to "TypeScript"
https://sourcegraph.com/kubernetes
[x] Change "Search the trending and most starred Kubernetes repositories on GitHub. Explore with search examples below." to "Explore Kubernetes repositories on GitHub. Search with examples below."
[x] Change "Browse diffs for recent code changes in the community:" to "Browse diffs for recent code changes"
https://sourcegraph.com/golang
https://sourcegr12aph.com/android
[x] change "Search the most starred Android repositories on GitHub. Explore with search examples below." to "Use these search suggestions to explore popular Android repositories on GitHub."
[x] change "An intent filter is used to specify the type of intents a component would like to receive. An intent filter can accept 3 types of elements -, and elements." to "Intent filters specify the type of intents a component would like to receive. An intent filter can accept three types of elements - , and elements."