establish procedure to continually curate list of Search Topics

[jf990]

I am not sure what the definition is for our search topics. Are they platforms, languages, capabilities, or what? The list isn't making any organizational sense, I was wondering if we had a definition of what should be here.

For example, we have JavaScript and Web-Development, but we do not have iOS or Android yet we have objective-c and java. I would think developers search for ios or android projects would be searching by those topics, not the programming language. Also no .net or qt or qml. we have native, but I am not sure how that topic is useful, no one is looking for native projects instead they look for projects in a specific platform/technology they can load into their ide and build (such as .net or wpf, android, ios, etc). We have utilities and government but missing a whole bunch of other industries. and capabilities, we list some, but routing and navigation and geoenrichment are missing.

The runtime projects are going to be tagged by the SDK used in the project, so they would be using topics we currently don't support. I think we should add them.

@alaframboise @jgravois what do you think?

[jgravois]

we do not have iOS or Android yet we have objective-c and java

this is because so far i have only ported the list of official GitHub 'languages' that we actually have projects in.

neither AL or myself had any delusions that we could come up with a definitive and complete list of tags that would please everyone. because of this we were intentional when we announced the new project to explain that developer teams across Esri are welcome to suggest additions.

please go ahead and propose any changes that seem appropriate to you in /src/data/search-topics.yml but keep in mind, if you don't actually have development teams interested enough to add the topics you're suggesting to their own projects we'll end up exposing new good search suggestions that don't return any results.

[jf990]

understood. we need to set forward the rules behind these topics. part of the issue is defining the topics, the other part is getting repo owners to categorize their projects by the topics that support the most effective search.

I'm not yet convinced if language is a useful topic. Take JavaScript for example, vs. web-development. JavaScript could be a browser or node or embedded or maybe even qml project, that's too diverse to be useful. And it would miss TypeScript projects that may be a match. A developer may rather search for web-development or node to find projects of interest and avoid a lot of false positives. Same with Java, C#, etc. I would think in this scenario developers are looking for solutions, not languages.

Something to think about. I'll propose the updates once we have specific projects that match. The runtime ones are definitely coming soon.

[jgravois]

you aren't going to have to work hard to convince me to remove topics.

whether they are redundant, confusing or not actually in use, we absolutely need to revisit the list. my vote is that we wait a month or two to see what new topics are suggested and how many of the topics we suggested actually caught on and then make our first 🔪 s.

[alaframboise]

I think it's ok for repos to have their own topics beyond what's in the list on the .io page, but we I think we missed some important ones e.g. iOS, qt... We didn't really have time to collaborate and come up with the perfect list, but it's easy to add them now.

In general however, it's my understanding is that we are 1) roughly following GitHub's guidelines, 2) replacing the old tags (at least the good ones) with topics. This includes topics for the language.

https://help.github.com/articles/about-topics/

Helpful topics to classify a repository include the repository's intended purpose, subject area, community, or language.

[alaframboise]

@jf990 actually, in my original list I had ios, qt and many other languages that didn't seem to make the cut...

#73

[jgravois]

thats my bad. in my original pass at rewriting search i was managing both topic queries and native language queries so i didn't include the ones that GitHub doesn't recognize. when i refactored to search topics exclusively i forgot to add them back in.

we all know that updating the list is trivial. hopefully we also agree that there is no point in adding suggestions to the UI that don't return results.

i see 4 options:

1. make specific additional suggestions to the runtime teams and wait until after they've added the new topics to at least a few repos and then put them in the UI
2. make some executive decisions and have AL add new topics to a handful of repos to plant seeds and hydrate search
3. wait to see if they notice the problem on their own and suggest their own additions
4. point out the issue to them and ask them to make their own suggestions

i don't have a horse in this race. on one side, i feel like language topics are inherently redundant but i also understand the perspective that we have projects that might best be grouped using a language name or language variant.

[jf990]

Some combination of all 4. I liked your earlier suggestion to wait a bit (a month) and see how it pans out. Its a bit the chicken or the egg: we need repos tagged so the search returns results (currently most topics return 0 results) and repo owners need to know what topics to use for best results.

I suggest we keep it fluid, we'll make topics updates as we see fit/useful and together we'll continue to hone the list.

[alaframboise]

@jgravois no worries, maybe we can top up the list with the main languages that we know will give results in the future as things get tagged?

Also, keep in mind that in my original email I told everyone to email the admins if they wanted a topic added, but I think adding an issue is fine too now that we are over the hump.

[alaframboise]

@jf990 RE: language, I'm not a fan of depending on language in anyway because GitHub still classifies projects incorrectly and I've already had to help some folks manually set the linguistics for their project.

https://github.com/github/linguist

Topics give us a more definitive way for admins to set the language correctly.