Stewardship of this repository

[asbjornu]

It has been discussed for a while now how this repository is being maintained, as exemplified by @goofballLogic in #24 (comment). The NuGet team seems to have run out of active maintainers and pull requests remain open for months and issues open for years without any attention.

A discussion on the public-linked-json mailing list brings forth different options for how the community can contribute to bring the stewardship of this repository back on track so the .NET community can have a well maintained and up to date JSON-LD implementation.

Here are some suggestions for how to move forward:

• Set up a semi-automatic Sharpen-conversion from jsonld-java that will be repeated every now and then.
• Add more maintainers to this repository.
• Move the repository to a different organization.

We would love to get some input from @emgarten, @sblom or anyone else that have ownership status of this repository at the moment, because the current state of affairs is unfortunate.

[emgarten]

@skofman1 @rrelyea would you help make a decision on this?

I would really like to see this project move forward, and these look like great suggestions for allowing that to happen.

NuGet gallery still uses this library as far as I know, but the current implementation works fine for them and there has not been any work done by the NuGet team in quite some time. My guess is that consumers of nuget.org aren't reading it as json-ld, so even if things are incorrect, no one is reporting it. Which is why this isn't being updated.

The issues and PRs coming in for this repository require a lot of technical expertise on RDF and json-ld. It takes a effort to determine if a PR is actually the correct fix for an issue just based on the json-ld output. @sblom, @johnataylor, and myself who previously worked on this library are no longer on the NuGet team which has made this more difficult.

[skofman1]

@asbjornu , @goofballLogic thanks for bringing this to our attention. I will work with the team to determine the best course of action.

[gkellogg]

Note that jsonld-java is, itself, only lightly maintained. Other implementations are updating with features from the JSON-LD 1.1 CG Spec, and a new JSON-LD Working Group is being chartered, so if developers are interested in moving this version forward, it would be shame if they are handicapped by less progress on the jsonld-java side.

There is no substitute for active and interested maintainers.

[danbri]

• Tom Marsh (@tmarshbing) who coordinates Microsoft (incl. Bing's) participation in Schema.org

[tmarshbing]

Thanks @danbri. I will follow up with @skofman1 offline.

[skofman1]

Thanks everyone, for you enthusiasm in making contributions or taking this repository forward.

After a conversation internal to the NuGet team, we realized that we did not have any expertise left on the team who can successfully maintain this repository and either contribute directly to it or manage our community contributions. While NuGet.org has a dependency on this package, we have not really required any code changes for many years now, and we don’t see this changing.

In order to take this repository forward as expressed by the community, we are proposing the following:
• We will work with anyone in the community who has a strong interest in this code-base to transfer ownership of the repository to you (or a set of you).
• We will transfer the repository from being under the NuGet organization to another organization that the owners decide.
• We will also transfer ownership of the packages on NuGet.org to another account that the owners decide.

There will be no changes that the NuGet team will propose the licensing terms, code of conduct, and such and we will defer all future decisions regarding the code in this repository to its new owners. The transfer of ownership will be as-is.

Please let us know your thoughts about this plan. If there is general consensus, we will work on the next steps to identify a set of future owners for this repository.

[goofballLogic]

I have a strong interest in this code base.

I'll mention this on the public-linked-json W3 mailing list to see if others are interested, and to encourage brainstorming ideas about where best to host the repository moving forward.

Note that I personally would have no objections to maintaining the repository within the Nuget organisation as the Nuget name lends some authority to the package. However, I can understand you may not wish to have outsiders maintaining a package in your name.

[tpluscode]

have outsiders maintaining a package in your name

Isn't that the essence of open source collaboration? 🙃

As long as there is an active maintainer who would take care of code quality and coverage I think it's a good choice to stay under the NuGet organisation.

[goofballLogic]

Those who responded on the public-linked-json W3 mailing list agree that it would be good for the repo to remain part of the Nuget organisation. This would mean:

1. Creating a repo-specific group for maintainers with administrative privileges over this repository and adding volunteers
2. Specifying the members of this group as "Package Owners" for purposes of publishing to Nuget

Is this something that you are open to @skofman1 ?

[goofballLogic]

@tmarshbing - as mentioned above to @skofman1 we think it would be good for this library's profile to remain within the NuGet organisation. Is it possible to set up a group of maintainers (I am volunteering) with administrative rights over just this repo, and the ability to publish to NuGet ?

[skofman1]

@goofballLogic , @tpluscode ,

As long as there is an active maintainer who would take care of code quality and coverage I think it's a good choice to stay under the NuGet organisation.

There's no one in the NuGet team that can maintain the repository, since, as was mentioned before, we have no knowledge left on the team on this code base. We can't lend our name to a code base we can't guarantee the quality off, hence, to allow open source collaboration, the repository must move out of NuGet's GitHub organization.

[goofballLogic]

I suggest that the repo is moved to the https://github.com/linked-data-dotnet organisation which I have set up as a (temporary?) location so we can start fixing things. @tpluscode @asbjornu @gkellogg @tmarshbing - anyone wish to propose otherwise?

[asbjornu]

@goofballLogic: As the repository can be moved from @linked-data-dotnet whenever we find a better home for it, I give it my two thumbs up. 👍

[tpluscode]

I was going to propose https://github.com/json-ld but I see that it doesn't really host any implementations. I guess I too agree with @goofballLogic. The only other org I found is https://github.com/RDF-Utilities-dotnet which doesn't offer much more visibility either.

[rvesse]

@tpluscode You can always put in under the https://github.com/dotnetrdf org for old times sake ;)

[tpluscode]

HA! It did cross my mind but I don't know what @kal would say given recent effort for dotNetRDF's own JSON-LD support 🙃

[kal]

Thanks @tpluscode! As much as I would like to support this code base too I think I have my hands full with dotNetRDF :-)

[tmarshbing]

The proposal to move to https://github.com/linked-data-dotnet sounds good to me.

[goofballLogic]

Hi @skofman1 looks like we're ready to move on this.

1. Lets go ahead with this transfer to https://github.com/linked-data-dotnet please
2. Could you add me as an owner on Nuget (https://www.nuget.org/profiles/goofballLogic)

@asbjornu we need at least one other owner for the org to be secure. Shall I add you? Any other volunteers?

[asbjornu]

@goofballLogic: Sure. We can always rejuggle ownership and administration after the transfer is complete.

[skofman1]

Sounds good @goofballLogic !
Will handle the transfers next week.

[danbri]

This sounds sensible. We could also point to the project from Schema.org somewhere if that helps. Better JSON-LD support in every language is certainly something in line with our efforts...

…

On Fri, 27 Apr 2018, 16:54 Svetlana Kofman, ***@***.***> wrote: Sounds good @goofballLogic <https://github.com/goofballLogic> ! Will handle the transfers next week. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#26 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKZGUrzm2109DCWppr3Jei-X0IA9ATxks5ts6-dgaJpZM4TNzI3> .

[skofman1]

@goofballLogic , I need permissions to create repositories in https://github.com/linked-data-dotnet in order to perform the transfer.

[goofballLogic]

Just invited you ⁣Sent from TypeApp ​

…

On 1 May 2018, 17:44, at 17:44, Svetlana Kofman ***@***.***> wrote: @goofballLogic , I need permissions to create repositories in https://github.com/linked-data-dotnet in order to perform the transfer. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #26 (comment)

[skofman1]

Repo transfer completed 😄
Regarding the package on nuget.org, I recommend that you create an organization to own the package, and add all other contributors to this org. Documentation here: https://docs.microsoft.com/en-us/nuget/reference/organizations-on-nuget-org

[goofballLogic]

Thanks @skofman1 I have set up https://www.nuget.org/profiles/linked-data-dotnet for this purpose

[skofman1]

@goofballLogic , ownership request sent. After you accept I will remove 'nuget' as an owner.

[veikkoeeva]

In my humble opinion, a general purpose .NET Standard 2.0 compatible, easy to digest JSON-LD 1.1 library is difficult to find and considering the importance, I find it a bit odd there isn't one baked into the official framework. Just in case, I'd like to page @RehanSaeed of https://github.com/RehanSaeed/Schema.NET. It'd would be great to see efforts pooled, unfortunately for the time being I lack the expertice to contribute much anything. It's the knowledge-available time gap.

[goofballLogic]

Plans exist to try and update the library by the end of next month. However, this will likely be just getting the 1.0 version up to date.

Once updated, the upgrade path to 1.1 should be much simpler and PRs will be welcome.