Skip to content
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

First drawbacks of the contribution process #15

Open
amivanoff opened this issue Nov 22, 2024 · 3 comments
Open

First drawbacks of the contribution process #15

amivanoff opened this issue Nov 22, 2024 · 3 comments

Comments

@amivanoff
Copy link
Contributor

We received the first "not from the repository maintainers" contribution. Thank you @jeswr!

There are some minor issues with the contribution from my point of view. And it could be used to improve our contribution process.

We ended up here with some "shared implicit style conventions" which makes it hard to prepare, review and accept pull requests from the community.

Some examples below from this contribution:

image

image

Some mismatches with our current style conventions:

  1. The "Validators" lists are sorted by programming language by @VladimirAlexiev. Maybe we should state this explicitly for readers and contributors? At the top of the section or at the beginning of the README? Or in the Guidelines?

  2. Personally, I think it has too much badges. Maybe we should state the recommended format for a list item too?

    • We are using only two badges:
      • "last stable version" (from any most common binary repository or even GH Releases)
      • and "last repo activity" (is the project dead or alive).
    • license info -- we are using just text in code quotes. Not sure is it worth to use a badge for a license info like in chore: shape conversion tools #14. The downside of badges here -- the text is not searchable
    • programming language -- we are using just text in code quotes
    • build status and dependencies info -- this info is an overkill?
    • badge for documentation -- we are using hyperlinks, maybe it is better then badges?

Open questions:

  • Should we refine our current list item format?
  • Where is the best place to put our style advices like "list sorting", "list item format", "approach with badges"? In The Contribution Guidelines only? Or some advices/descriptions should go to the README?
@amivanoff
Copy link
Contributor Author

Another addition to the mismatches and a candidate to the style guideline:

  1. In the description, too many URL links to general things or common to all section's items (like RDF, SHACL, ShEx, or Java), could hurt list readability. Only meaningful item-specific things should be made URL links.

rudof - a library that implements Shape Expressions, SHACL, DCTAP, and other technologies in the RDF ecosystem. The library is implemented in Rust

jeswr added a commit to jeswr/awesome-semantic-shapes that referenced this issue Nov 22, 2024
Resolves issues from w3c-cg#15
This was referenced Nov 22, 2024
@jeswr
Copy link
Contributor

jeswr commented Nov 22, 2024

Can I make a somewhat drastic suggestion - have the list described in RDF and generate this README using those RDF descriptions.

@VladimirAlexiev
Copy link
Collaborator

I agree the badges are a bit too many.
And I agree that of all hyperlinks about rudof, only rudof and DCTAP should remain (because that's more obscure than SHACL/SHEX)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants