Offer to help with housecleaning

[Henry Andrews]

Hi folks,

  After going through various repos, issues, wiki pages, and email threads (particularly https://groups.google.com/d/msg/json-schema/ih8Xqr-2c24/qASSXB6VAQAJ ), it seems like there is a shortage of people willing and able to slog through everything in the old repo (and anywhere else that's outdated) and consolidate it all into the new repo.  It also sounds like there's an inability to close/clean up the old repo due to prior contributors no longer being around.

  I would be happy to work on this.  I propose to do the following non-destructive things, which I will start doing after a couple of days if no one objects. If someone shows up later and objects, I will not take it personally and will be happy to roll it all back.

* Go through the issues in the old repo:

    ** Summarize and re-file each one that still seems relevant in the appropriate new repo.  Label them as migrated.

    ** Link the new issue to the old for context, and @mention everyone from the old issue.

    ** Link the old issue to the new issue (unless someone here can and prefers to just close them out).

    ** Post a list of issues that I didn't re-file here with an explanation of why I did not move them over, so we can discuss what to do with them.

* Go through the wiki pages in the old repo:

    ** Take each thing that looks like a proposal and file it as a new issue, or add any missing info to existing issues on the subject.

    ** Link any such newly filed or updated issues to the old wiki page.

    ** Copy other useful pages, like the v3 to v4 Change Log, over more or less as-is.

    ** Update old pages to point to their new location / relevant issue, unless someone has a better idea of how to handle this.

    ** Post a list of pages I couldn't figure out how to handle here.

* Update / expand the new repo's wiki:

    ** Start a v4 to v5 Change Log page similar to the v3 to v4 one, summarizing the current state of major changes

    ** Create a page for rejected major proposals and go through old stuff to see what should be put there to avoid it coming up again.

    ** Update the front wiki page to explain the current status of v5 and v6, assuming I can figure out what that is.  I am fairly certain that we are not still in the two-week comment period announced over a year ago :-)

How does that sound?  Feel free to tell me to shove off, I just prefer to propose some actions instead of starting another "why isn't this happening?" thread.

thanks,

-henry

[Henry Andrews]

Actually after looking a bit more closely at the issue list in the old repo, I'll make a Google Sheets document categorizing them based on stuff like "spec proposal", "spec bug", "web site", "stack overflow question", "implementation bug", etc.  I'm pretty sure some of these intentionally do not have a home in the new repos.  I'll post the link here for commentary when I've got it sorted out.

thanks,

-henry

[Ben Hutton (@Relequestual)]

Hey Henry,

It's great that you want to and are able to commit some time to try and tidy things up and push things forward!

I agree with your plans on how to handle issues. I'd like to have time to do this myself, but I simply don't.

Regarding the wiki, I would wait for a response from Austin Wright (cc'ed) till you start changing or migrating wiki related things. He has an idea how he would like this to play out (I believe).

Currently it (still) feels like the project has no driving force behind it. I don't know how to solve that. It would be great if some big players that use it (amazon, google) could commit time to making it more awesome. Google has protocol buffers to look after already though.

Thoughts / reactions welcome.

Cheers
Ben

[Henry Andrews]

Thanks, Ben.  Reading back over my list I realize I tacked on stuff about actually editing some existing wiki pages- that's not "non-destructive" so I'd definitely wait on a more active agreement for that :-)

I've gone through and classified all of the open issues in the old repo (in a spreadsheet).  I think I'll look at the old wiki and take an inventory there, and then make a proposal about what to actually file as issues for the spec repo.  I don't think it will really be that many issues as less than half of the issues are new proposals, and many of them end up converging on the same ideas, some of which are also covered by wiki pages.  And then there are a few that are minor bugs for typos and stuff and maybe it makes more sense for me to just do a pull request with the fixes.

thanks,

-henry

[Ben Hutton]

Thanks Henry,

 

I can’t quite remember all the discussions with Austin, but I personally hate, and strongly advocate, not having suggestions in the wiki. I can’t stress how much I dislike the idea. Having them as issues makes sense.

If you have any suggestions on how to manage suggestions and issues better, in terms of tagging for categorisation and organisational reasons, then I’m all ears. (I’m sure I could come up with a few ideas, but I’d also like to hear what others feel would be the way to move forward, especially when others like yourself are able to invest time and would be using the system).

 

Great! Looking forward to your taking action! =]

 

Cheers

Ben

--
You received this message because you are subscribed to a topic in the Google Groups "JSON Schema" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/json-schema/nlio7qTE73Q/unsubscribe.
To unsubscribe from this group and all its topics, send an email to json-schema...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Henry Andrews]

Hi Ben,

  I had seen the discussion about consolidating on using issues for tracking, so my plan would be to move everything to issues in the new repo.  The wiki, IMHO, should be for high-level things like the road map of which version(s) are under development, where we are w.r.t. submitting a new draft, etc.  And tracking things like rejected proposals that we don't want to have cluttering up the open issue list.  But we don't want them re-filed either.

thanks,

-henry

---

From: Ben Hutton <b...@sanger.ac.uk>
To: "json-...@googlegroups.com" <json-...@googlegroups.com>
Cc: "a...@bzfx.net" <a...@bzfx.net>
Sent: Tuesday, September 6, 2016 8:28 AM
Subject: Re: [json-schema] Re: Offer to help with housecleaning

--
You received this message because you are subscribed to the Google Groups "JSON Schema" group.
To unsubscribe from this group and stop receiving emails from it, send an email to json-schema...@googlegroups.com.

[Ben Hutton]

Hi Henry,

 

I agree to an extent. The problem with the previous wiki is that anyone could edit the wiki, so everyone was adding things they wanted to see. If editing the wiki is limited to just those with committer access, then fair enough. I still think rejected proposals should be in issues and tagged as such. If you really want, there’s no reason there couldn’t be a list of those issues, although you could simply direct people to issues with that tag.

To prevent multiple submissions of the same suggestions, we could add an issue template which directs people that page / filtered issues list.

[Henry Andrews]

Hi Ben,

  My thought with the list of rejected ideas, as with the change log of accepted ideas, is to have a clear and concise listing of what was proposed and rejected.  Having just gone through all of the old repo's issues, it's very clear that you can't get a correct idea of what's going on from the issue titles.  Many issue discussion end up in a very different place than they started, or raise and discard much broader concerns along the way.  I would like to tag closed rejected proposals (as opposed to closed for other reasons), but I don't think it is sufficient on its own.

thanks,

-henry

---

From: Ben Hutton <b...@sanger.ac.uk>
To: "json-...@googlegroups.com" <json-...@googlegroups.com>
Cc: "a...@bzfx.net" <a...@bzfx.net>

Sent: Wednesday, September 7, 2016 1:15 AM