-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Review "tags" field in CfA's organizations.json #33
Comments
Did some quick research on this. I didn't find anything for:
It doesn't appear these tags are being used widely in the wild. I think @tdooner could speak to this more accurately, but I think the purpose of these tags is for querying CfAPI, as in
snake_case, or kebab-case? I'd vote for kebab-case to be consistent with our GH topic tagging recommendations, unless there's a reason the index prefers underscores to hyphens. I'd rather not have to remember that it's snake_case here, kebab-case there, and camelCase somewhere else.
I like the idea of whitelisting an official version for the ones that will be used across many brigades, and leaving them out of organizations.json. I'd still like to see a field on organizations.json to store a brigade's official topic tag, like |
@ckingbailey Yes, the tags are meant for filtering of the list of Brigades. As far as I know, the only usage in the wild is the Brigade website: https://github.com/codeforamerica/brigade/blob/master/cfapi/__init__.py#L84 I don't see a benefit to trying to represent these tags on Github repos, since they're different. The tags we're talking about for the project index are for tagging projects, whereas the tags in the CFAPI are for the brigades themselves. |
thanks for clearing that up @tdooner, these tags would be accurate at least for determining which organizations can be rolled up under I guess what I'm really seeking to figure out is, as we start collecting the brigade tag for projects (e.g. I could see it being useful for the crawler to apply these "inferred" tags while building the index. That is, tools using the index wouldn't need to know to include @ckingbailey thanks for surveying their use, sounds like we don't need to consider projects already using them so the question is just what can we infer from them?
|
I only maintain the tags for brigades tagged with "Code for America". The tags I maintain are: "Code for America Fiscally Sponsored Brigade", "Code for America Partner Brigade", and "Official". I don't maintain "Government".
The "Official" tag is relevant because I will remove it when Brigades are no longer part of the network. We probably want to de-list their projects from the index at that time. Other than that, idk, just the other metadata fields about the brigade could be useful in how we display the project (e.g. "Click here to go to the brigade's website!" or something like that). But that can probably be handled at a layer other than the index data layer.
Yeah, some people put those in there, and I didn't have the heart to remove them. |
I don't know how much you care about these tags @themightychris, but, you can also see how I maintain these tags. This is the script I have which reconciles the organizations.json file with Salesforce: I run this script once a week whenever there are changes to the brigade list. |
I just noticed that the
organizations.json
database CfA maintains (which drives both the index and CfA's internal tooling, and which CfA staff currently handle moderating brigade captain access to change) includes atags
field at the brigade level: https://github.com/codeforamerica/brigade-informationIt is documented as such:
tags
(Required) - An array of descriptors for your group.Some commonly used tags are:
Brigade
Official
Code for America
- Code for America BrigadeCode for America Partner Brigade
- A separate 501(c)3 nonprofit that is an official Code for America Brigade.Code for America Fiscally Sponsored Brigade
- A Brigade that uses a non-Code for America Fiscal Sponsor.Code for All
- Code for All network member ("Governing Partner")Code for All Affiliate
- Code for All network Affiliate PartnerFellowship
- organization is running a fellowship programGovernment
They appear to be applied pretty consistently in the data: https://github.com/codeforamerica/brigade-information/blob/master/organizations.json
Hack for LA, for example, has this entry:
There are however a few odd values like
midwest
added in without sufficient qualifiers to be a global tag.Some things this makes me wonder:
code-for-america
?recommended_project_tags
? Or should we just whitelist some of the existing tags in organizations.json like "Code for All" and "Code for America" and infer thatcode-for-all
andcode-for-america
should be applied too to all projects tagged to that brigade?The text was updated successfully, but these errors were encountered: