-
Notifications
You must be signed in to change notification settings - Fork 1k
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
add seal of approval and nc to README #6046
Conversation
I don't think that readme file is good place for such list. This is readme about data.table, not other pkgs |
where would you suggest we put it? |
Hmm, I didn't have any issue. It is under the "Community" heading after all. But on second thought, if there would be dozens of packages with the seal it would quickly get distracting. So maybe best is to link to a dedicated page instead. OTOH, a plaintext "check out the seals of approval+link" will likely be too hard to find & thus undermine the whole point. Possibly we could give it prominence on README in another way, e.g. once there's a logo, add it next to the data.table hex? Or put the hex next to the link? |
What if we make it as a vignette and link the vignette in the readme? |
I vote for @ben-schwen 's idea, would still give prominence without having too much space in the README. |
For me vignette also does not seem to fit. Wiki page probably the most... |
@jangorecki thanks for sharing your opinion, but can you please clarify why you think the vignette would not be a good fit? |
Vignettes are about package usage, not revdeps usage nor even listing "notable" revdeps. IMO this fits into new meta package, or if ewe want to have it in data.table repo, then wiki page. |
I agree vignette is probably not appropriate, vignette as I see it should be teaching user something, seal of approval is a bit of a stretch of that purpose.
Maybe there's some misunderstanding here, I don't see how a meta package would be relevant here. My understanding is the purpose of the 'seal of approval' initiative is simply to highlight some downstream packages that align with data.table by (1) importing data.table (clearly) and (2) generally following some key data.table package design principals like minimal deps, high performance, etc. In order for this initiative to be useful (as I see it) there needs to be some incentive to participate, mainly through recognition & highlighting by data.table itself. I only see meaningful traffic to the Installation wiki page, which is almost certainly being linked directly from search engines. So relegating this project only to the wiki pages will not be successful, IMO. The README, by contrast, is visited often; reaching there could provide a meaningful boost to visibility for "sealed" packages.
I don't see "seal of approval" as being "not about data.table", in fact, it's highlighting other problems that data.table can help solve. The In sum, as I see it, realistically this has to be part of README. The decision then is (1) Just don't pursue seal of approval or (2) Decide exactly to place seal of approval in README in a way that balances (a) focus of README on data.table without distracting with references to other packages and (b) seal purpose of highlighting specific noteworthy downstreams. |
closing in favor of Kelly's proposal here #5723 (comment) |
Closes #5723
This is a draft implementation of the Seal of Approval idea.
Preview at https://github.com/Rdatatable/data.table/blob/seal-of-approval/README.md#seal-of-approval