Call for more reviewers

[Iwan Aucamp]

Hi,

Currently Nicholas is doing most reviews and approvals, but he is only one person. I try and help out with reviews when I can but it would be nice if we could have some more people who actively do reviews as I think this is currently what holds progress back most and ideally this should not just rely on one or two people. If anyone has capacity and availability for helping process pull requests do consider helping out, I'm willing to do reviews on other repos in exchange.

Regards

Iwan Aucamp

[Iwan Aucamp]

I have been thinking more about what we can do, to get more people involved with RDFLib.

I really want to see RDFLib get better and be something which people feel comfortable in using in production, and for this a higher velocity is needed to clear out the issue backlog and keep contributors engaged.

Python is one of the most popular languages in the world and the accessibility of RDF on python greatly affects the viability of RDF.

There are a couple of non RDFLib affiliated python projects related to RDF, and I think one options is to reach out to the people from those libraries and see if they are willing to at the very least do some reviews on PRs.

I will reach out to some of them and see if there is any interest.

[Donny Winston]

Thank you, Iwan.

Feel free to `/cc @dwinston` on PRs you look over and would like another set of eyes on. I'll try to do what I can. You may remember me from https://github.com/RDFLib/rdflib/pull/1456 a few weeks ago. :)

I won't have much bandwidth over the next couple months, but by ~March 2022 I expect to be very interested in more active involvement with RDFLib (I have even been putting together a mini course using it).

Best,

Donny

--

http://github.com/RDFLib

---

You received this message because you are subscribed to the Google Groups "rdflib-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rdflib-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rdflib-dev/06c47560-17e6-49da-b9b2-30483e4bb303n%40googlegroups.com.

--

Donny Winston, PhD (he/him/his) | Polyneme LLC

https://donnywinston.com | https://polyneme.xyz

If I've emailed you, I'd love to speak with you.

Schedule a meeting (15min+): https://meet.polyneme.xyz

[Nicholas Car]

Thanks for the offer Donny and we do remember you! I’ll tag you on a couple of PRs and whenever you’re available we’d love to have more of your input.

Great to see another course unsung RDFlib out there! I used RDFlib + Mongo for my very first RDFlib-based system back in, I think 2013! It was pretty simple but used the ease of Mongo to store JSON with RDFLib’s JSON-Lad capability to store RDF docs.

Perhaps you could make a Mongo back-end Store for RDFlib?

Cheers,

Nick 

— 

Dr Nicholas Car

Data Systems Architect

SURROUND Australia

0477 560 177

nichol...@surroundaustralia.com

On 18 Nov 2021, at 6:12 am, Donny Winston <do...@polyneme.xyz> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/rdflib-dev/3a3f3cbd-c69c-43c0-8b46-a58550e5a050%40www.fastmail.com.

[Miel Vander Sande]

Hi all,

Happy to help, but I'm still very much a python newbie. Don't know if that's helpful?

Skills aside: is there any guidance on the rdflib governance, or perhaps soneone should write some contibutor/reviewer guidelines (without becoming too demanding)?

Best,

Miel

Op di 23 nov. 2021 om 08:55 schreef Nicholas Car <nichol...@surroundaustralia.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/rdflib-dev/E0D996C9-E439-4B79-920E-8242EB3859EE%40surroundaustralia.com.

[Wes Turner]

IMHO, I agree, there being a Code of Conduct referenced could invite contributions: 

https://github.com/jupyter/governance/blob/master/conduct/code_of_conduct.md :

> Original text courtesy of the Speak Up! and Django Projects, modified by Project Jupyter. We are grateful to those projects for contributing these materials under open licensing terms for us to easily reuse.

It specifies:

- [ ] an email address

- [ ] a form

- [ ] a Code of Conduct committee

- https://github.com/folkswhocode/awesome-diversity#readme

- https://github.com/digitalocean/engineering-code-of-conduct#giving-and-receiving-feedback 

"Adding a code of conduct to your project"

https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-a-code-of-conduct-to-your-project

Is the issue that everyone agrees but who's the committee?

> "Free and Open Source Governance"

>> An indexed collection of governance documents from Free and Open Source Software (FOSS) projects.

https://fossgovernance.org/

>>> FOSS Governance Zotero Collection:

https://www.zotero.org/groups/2310183/foss_governance/item-list

To view this discussion on the web visit https://groups.google.com/d/msgid/rdflib-dev/CAHeRLWtwA5V4XHa8hdyAbGJ9z9m6qWbLYPNfB72e4zr3o6d8fw%40mail.gmail.com.

[Wes Turner]

REQUEST: Suggestions for Code review practices in general and for rdflib/ projects?

- https://github.com/joho/awesome-code-review#books

- [ ]

What unique constraints and opportunities are there in code review of software currently mostly written in Python for {W3C,} Linked Data spec implementation and domain application?

*****

FWIW, here's (yet another shorthand) representation for RDF/RDFS vocabulary specification, which is useful for describing tests for linked data tools:

```

C: schema:Course

C: :Course

- C: https://schema.org/Course

  - P: hasCourseInstance R: https://schema.org/CourseInstance

- P: schema:hasCourseInstance

  D: schema:Course

  R: schema:CourseInstance

C: schema:Course

  - Thing > CreativeWork > Course

  - Thing > CreativeWork > LearningResource* > Course

```

[Iwan Aucamp]

Hi Miel,

I think all reviews and approvals are valuable data points, however they will likely all be treated with something not entirely unlike bayesian inference by maintainers. If I as a maintainer see an approval from someone I don't know I will likely not value it much, but if they pointed out valid problems and gave good suggestions to a pull request this will also increase the value that I as a maintainer assigns to an approval from the reviewer. It will likely take some time to gain trust, but that is not a good reason to not try.

Some considerations:

- Not every comment on a PR has to be coupled with a review outcome (approval, request for changes, etc) - comments can just be comments.

- You should not approve PRs unless you have very high confidence in them, because of this your python skill level does not really matter as long as you know what you do not know and do not assume things without being sure.

- Don't be afraid to ask questions in a PR.

So in summary, please do review PRs if you have capacity for it, approving a PR will not necessarily mean that maintainers will have high confidence in it, but they will have higher confidence than if nobody else approved. And your python skill should not be an impediment and reviewing PRs will definitely help you increase your python skill level.

Regards

Iwan Aucamp

[Graham Higgins]

Iwan writes:

> Not every comment on a PR has to be coupled with a review outcome (approval, request for changes, etc) - comments can just be comments.

This is so true. I've been going through some of the older PRs, trying to find some low-hanging fruit but it's not always straightforward. All of the older PRs will need re-working by the contributor (or adopting by someone). A goodly number of PR discussions have been suspended pending development/milestones. Some of these suspended discussions can be progressed without actually writing any code.

Take the 28 May 2020 PR 1087 “Fix Issue #948” as an example ...

The discussion starts with

> “We have provided the solution for issue #948 . In this we have allowed objects to have special characters with forward slash to make it a valid one.”

The discussion ends with tgbug’s prompt response:

> “As the test results show, this approach will not work. The place in the code to start on this is probably in <rdflib/rdflib/namespace.py:split_uri> , but the issue related to curies vs qnames will also have to be addressed to really address #948.”

Issue #948 (from 19 Dec 2019) is titled: “Prefixed names does not allow escaping (turtle 1.1) - It is not possible to use escaping when using namespace prefixes. Creation of URIRefs warns about the problem and the serializer fails to create turtle 1.1 output.”

This #948 discussion ends with tgbugs’ 10 March 2020 comment

> “This is not just a parsing issue. It almost certainly will require changes to how curie suffixes are serialized. It may have unexpected interactions with the uri splitting code and might depend on #649 to get the expected roundtripping behavior, and some additional work to serialize escaped characters in local names correctly.”

As it transpires, #649 is actually tgbugs’s 16 March 2020 PR (“namespace.py fix compute_qname missing namespaces”) which nicholascar committed to master on 16 March 2020.

So, the #948 issue discussion can be updated with this information and the #1087 PR can, in turn, be revisited to check if the proposed changes are still valid w.r.t RDFLib 6.0.2 and whether the PR does actually fix the #948 issue.

Sadly, the actual work of updating and checking the #1087 PR has to be done locally.

I already have a clone of RDFLib in my home org and Github won't allow me to make another, so I can't clone a PR contributor's repos, merge with RDFLIb master and then issue a PR on their branch to bring it up to date and so progress their PR.

The best alternative that I've come up with so far is to clone their repos locally, merge with RDFLib master locally and then create a new branch to contain the now-updated PR.

Cheers,

Graham

[Iwan Aucamp]

A bit of an update here, we have adopted a code of conduct (https://github.com/RDFLib/rdflib/blob/master/docs/CODE_OF_CONDUCT.md) and we have defined some pull request guidelines (https://github.com/RDFLib/rdflib/blob/master/docs/developers.rst#pull-requests-guidelines and https://github.com/RDFLib/rdflib/blob/master/.github/PULL_REQUEST_TEMPLATE.md) - it does not quite go into that much detail about how to review pull request, but it gives an idea of what the preconditions are for merging. I may expand on these things as I have time but any feedback or further suggestions are also welcome.

I'm thinking of making a GitHub group (i.e. team) called "rdflib-reviewers" and adding people in there who are open to being tagged on reviews and then tagging the group on reviews, if anyone is interested in being in the group please let me know, of course you don't have to review everything you get tagged on but at the moment I basically just tag the core maintainers and Graham Higgins, as Graham has been very helpful with Reviewing PRs. I'm also open to other options, but my aim is to create a surplus of reviewers for PRs, as currently we have somewhat of a reviewer deficit.

[Miel Vander Sande]

Hi Iwan, all,

My python skills have improved over the months and since it's essential for my organisation that this lib progresses, I want to give it a shot :) If you want, you can add me to the reviewers group and assign some of the simpler ones.

Best,

Miel

Op di 19 apr. 2022 om 00:28 schreef Iwan Aucamp <auca...@gmail.com>:

--
http://github.com/RDFLib
---
You received this message because you are subscribed to the Google Groups "rdflib-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rdflib-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rdflib-dev/bfbe8bdd-6735-46e4-9b64-f5f4fcf0a0e8n%40googlegroups.com.

[Nicholas Car]

Thanks Miel, that's great to know!

I'll be putting some time next week in to selecting PRs to merge before a next release, so I'll look out for some for you to review then.

Cheers, Nick

------- Original Message -------

To view this discussion on the web visit https://groups.google.com/d/msgid/rdflib-dev/CAHeRLWsSsKOLpFbEuruCzTyzyUebUOx8WdLBBPFX7YW2Go9WYA%40mail.gmail.com.