Official-ify this fork
loganvolkers opened this issue · comments
There's a few things to do to make this fork more official.
- Release a new version on NPM (Using semver plz)
- Setup a
.githubfolder tool - Comment on individual issues and PRs and request people move their issues to the new repo
- Talk to @jdorn if he ever returns from the dead
- Setup protected branches
- Submit an application to the JsFoundation: https://js.foundation/
- Write a blog article about the above
I have reserved the json-editor organization namespace on NPM: https://www.npmjs.com/org/json-editor/
Hi Logan, thanks for taking the initiative with this project! Have you reached out to @jdorn using the contact details on his website? If not I'm happy to shoot him an email, which might be a more reliable way to reach him than via github mentions :)
I would suggest as well that if there is no reply from @jdorn then the demo page in the readme should be replicated on a different server and an acknowledgement/link to the homepage of his site. This will both preserve the great demo page if his site goes down, and it will prevent superfluous traffic to the demo page on his site.
Hi everyone. Thanks for taking initiative on json-editor and keeping it alive in my absence. Maintaining the project became too time consuming and overwhelming and I had to take a break. I'm happy to support this fork as the official version going forward. What can I do to help the transition?
@jdorn Great to hear from you!
Also sorry for not chiming in earlier from my side. I am very happy to see this project gaining some traction again. Thanks to @xvaara and @loganvolkers for taking care of setting up the fork.
Just some background information from our side... We're using json-editor heavily in our PHP app templates. I don't code that much with JavaScript, but we have several JS-dev in-house, but I surely can help with testing.
@jdorn I think the least effort, highest impact thing you can do is to provide access to the project assets to this project's owners:
- Grants access to original github repo
- Grant access to NPM package
- Grant access to bower package
- Grant access to website (noticed it's your personal website so a redirect may be more appropriate?)
That will let us migrate the project to this fork under a Meritocracy governance model source
Alternatively if you want to maintain heavy control of the project, you could remain our BDFL (Benevolent Dictator for Life) and we could govern the project that way source
I think one of the main points should be the NPM support. Everybody uses npm nowadays, and not being able to install this library through it is a deal breaker.
What about the CDNs ? They are an important way of distribution and nobody is talking about them
Not a bad idea also to edit the main page so it doesn't link to the original pages and downloads. It's easy to wind up back there by mistake by following the links in the main readme.
Other than that, I was very happy to see this project getting jdorn's official blessing.
I did some work on https://github.com/json-editor/json-editor/tree/develop - including fixed testing.
For publishing it on npm we'd need a release process which builds the dist files, see also #17 (comment)
Test & build has not to be done with Docker, for sure - feedback about this is very welcome.
👍
@loganvolkers We'd be ready to start with some alpha releases, but we would need access to the npm organization (CC: @marc7000) see also #24
@jdorn There are people going to the old repo, ie. jdorn/json-editor#524 - if we make the final transition, I'd suggest to add a note to the original repo and set it to read-only
@json-editor/maintainers I'd also merge develop into master to go ahead with the development, please give me some feedback, about this and the other points.
Why do you need control of the organization? It will be enough to unpublish the original package or ask the npm support team to transition that package to another user
Why do you need control of the organization?
I do not need to control the org, but I need the right to publish releases. Also I am not experienced considering npm, but @marc7000 and I are working on that.
It will be enough to unpublish the original package
I won't do that, the current package can stay under its namespace, that won't break anything.
@schmunk42 send me the NPM usernames of people who should have access to the NPM org and I can add them.
I suggest we use np (https://github.com/sindresorhus/np) to do our releases to NPM, I've found it greatly simplifies the deployment and ensures good quality releases.
I think the first step towards am automatic publishing life-cycle and chsngelog generation is to adopt a commit convention. It will allow not only have a consisten style of commits but also automatic changelog and automatic version bump based on the type of commits. I'm not sure how np decides which should be the next version
@schmunk42 send me the NPM usernames of people who should have access to the NPM org and I can add them.
From our side this would be:
We also tried np and while it does a some things great, it also has some drawbacks.
As said, I am not very experienced regarding npm - we usually do our releases (PHP & Docker) like this:
- feature freeze
- merge
- build & test
- create
latestor master or a tagged version on a tag (we usually "just" tag when a commit has passed tests and look like expected)
I'd prefer a release process in a CI (eg. Travis) but I am open for discussion.
PS: I've updated the list in the inital posting.
@loganvolkers How about the npm organization? I think we don't have access yet.
Access has been granted to NPM org for schmunk42 and marc7000
@loganvolkers FYI: I reallowed merge commits, since it's very hard to track changes from such a huge amount of different PRs, when everything is squashed.
So can I now install json-editor with npm?
Yes, npm install @json-editor/json-editor
@schmunk42 Thanks :)
Given all the issues that are being created, I think it'd be useful for us to setup an issue template. There's support for this by setting up a .github folder. Here's a tool that can generate this.
@schmunk42 since you've taken point on dev, do you want to put something together? At this point I think that any default issue template is better than none.
Also maybe we should turn on stalebot? https://probot.github.io/apps/stale/
github folder
If I find some time...
stalebot
I don't think we need it yet.
I'm not sure about how branches are handle here, it looks a bit messy.
I think issue template is a good idea more than a Stalebot so that issues can be understood easily and discussed.
@Mikescops I cleaned the branches.
@loganvolkers Can I remove the branches v1.0.0 and docs?
I'd also close this issue then, please feel free to write a blog posting.