Maintainers

[DesignSkeptic]

I would like to make some PRs for this project but I noticed that it has been unmaintained for about a year. Is their anyway someone can join to become an additional maintainer for the project?

[manton]

Sorry, I’ve been thinking about how best to handle this. Part of the problem with all the pull requests is we migrated the website to a different host and there’s not a great workflow for going from merging them in to actually deploying the change.

I think I’ll go through the PRs and manually update the site where I can. Then we can reevaluate if more needs to be done.

Thanks.

[matklad]

As a data point, I am evaluating if I should switch my blog to json feed.

I absolutely love the format itself. It is simple, and it is done. It reveals the fundamental simplicity of the thing, hitherto concealed by over engineered XML.

But there are two major sticking points for me:

The landing page at https://www.jsonfeed.org/ is underwhelming. There’s no clear link to the spec on it, there’s no example! Instead, it is a list of two blog posts from years ago.

And, yeah, the state of repository is a bit of a disarray, with tones of open PRs and issues, some recentish, with no response. To clarity, I don’t think there needs to be much work done here, but responding to some of the issues with “thanks for the suggestion, but no, the thing is finished” would help me understand that it is indeed finished rather than abandoned.

Great work on the spec itself, I wish I’ve learned about it earlier!

[matklad]

Part of the problem with all the pull requests is we migrated the website to a different host

Consider hosting on GitHub pages (keeping domain name, of course). It feels like it’ll long term minimize “ops” pain.

[DesignSkeptic]

Agreed. The website can be deployed statically to GitHub.

[FelicianoTech]

I've been thinking about this for awhile and since there's still no progress here, I'm forking the website. I will pull in a bunch of these assorted repos into one place, get the website updates/add more information, etc. In order to not spend any money at the moment, I'll host it as a subdirectory of one of my Linodians project until I figure out where to go from there.

If you're interested in the new website, you can view the new webpages here: https://www.linodians.com/jsonfeed/ That is a direct link and I'm not linking it from the main navigation yet. The website is built with Hugo.

If you're interested in contributing, the GitHub project is: https://github.com/linodians/www.linodians.com and the source directory for the JSON Feed section is https://github.com/linodians/www.linodians.com/tree/trunk/src/content/jsonfeed. I also made a list of tasks that I want to tackle so far for the restarted project here: linodians/www.linodians.com#10

---

To the original authors, my contact email is on my profile, get in touch if you're upset, or if you'd like to contribute as well. I love what you've made and I just just want to see it flourish, not wither away.

[manton]

There has actually been some movement on this recently. Just last week we deployed some changes to the JSON Feed Validator website.

I don’t think a fork is necessary. Better would be for people to be able to contribute and have everything in one place so users aren’t confused.

[manton]

I’ll follow up in more detail tomorrow, but just wanted to post a quick comment. I’m glad people are interested in helping get the word out about JSON Feed. Thanks!

[DesignSkeptic]

I think a fork is justified here. I posted almost a year ago today, and the repo still looks the same as it did 2 years ago. Once there is more activity in this repo and/or additional maintainers, then it would make sense to move any new improvements back over.

[manton]

Ah, I can see how looking at the repo it seems like nothing has happened, since the website was moved out of GitHub. It’s updated separately.

Here’s what I’m going to do next:

• Merge the tools and libraries PRs and add anything missing to the website.
• Come up with a new mechanism for website change requests.
• Make sure there are multiple admins on the website, not just me.

[DesignSkeptic]

That sounds good. I understand your desire to maintain control over your project. However, it can be quite frustrating for contributors when there are open PRs and issues from over 7 years ago without any status updates. It would be really helpful to know whether these contributions might be included in the future or if they need specific changes to move forward.

For a project aiming to become a widely used standard, having some communication about the status of long-standing contributions would go a long way toward encouraging community involvement.

I would recommend adding additional maintainers and moving the website onto GitHub, since the Microblog platform seems to be better suited for blogs (if it cannot be integrated with GitHub). It also seems that some GitHub issues were already resolved, they just need to be marked as complete or not planned.

[manton]

Thanks. Moving the site to Micro.blog wasn't really about control, just was easier for me to manage with everything in one place with my other sites. (Micro.blog is fine for static sites, not just blogs.)

I agree that managing it in GitHub is probably more accessible for everyone.

[matklad]

I've been subscribed to all activity on this repo for a while. While there was a flurry of work around the time of fork announcement, it seems that not much was happening since (modulo a bunch of comments from a particular GitHub user).

From my observer's perspective, fork of the website is 100% justified at this point.

Though, @FelicianoTech, I strongly encourage you to make it a proper self-contained project, not affiliated with linodians.com. For long-term viability, it's imperative that code, ownership, and branding of JSON feed website isn't entangled with any other project. Otherwise I feel we are at risk of repeating exactly the same story where no one is empowered to make improvements, because the thing is tied into some unrelated infrastructure :-)

I would also strongly encourage to not fork the spec itself and just freezing it instead. Given the quality of the spec, I'd strongly prefer that all changes, if any are needed (!!) are approved by original authors (if you do fork, imo it'd be a good idea to also invite original maintainers).

I would also recommend using GitHub+GitHub pages or https://codeberg.org for storing the source of truth for the website source code, and org permissions.

But also, it's your fork and work, so don't take the above too seriously :-)

[manton]

There are things going on that are not yet visible in the GitHub activity. For example, I talked to the IndieWeb founders a few weeks ago about transferring everything to the IndieWeb's GitHub organization. I think that alone will resolve some of the concerns here. Forking the website isn't really going to help anything and will just fragment the documentation.