Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

All profiles should be reviewed #19

Closed
stuartpb opened this issue Apr 15, 2015 · 6 comments
Closed

All profiles should be reviewed #19

stuartpb opened this issue Apr 15, 2015 · 6 comments

Comments

@stuartpb
Copy link
Member

stuartpb commented Apr 15, 2015

I want to mandate the presence of the "Reviewed" field for all profiles (so at least they need to be reviewed before inclusion). This will entail reviewing all existing profiles:

(checklist removed)

@stuartpb
Copy link
Member Author

Structural aspects that need to be checked / fixed when reviewing profiles:

@stuartpb
Copy link
Member Author

stuartpb commented Feb 7, 2017

Okay, quick back-of-the-envelope calculation says I can knock all of these out by the end of the month if I accomplish five reviews a day.

That seems... maybe manageable, but, of course, the big thing is, what do I want a review to entail? The reason I've made so little progress, really, is because each review I've done has involved so much other stuff, like, in a lot of cases, figuring out what happened to a site, or how something I wrote before relates to what I'm doing now, and stuff like that.

So... ech.

@stuartpb
Copy link
Member Author

FWIW, what I'm finding right now is not so much that I'm getting blocked on the reviews themselves, but that I'm getting swamped by all the refactoring I'm doing between reviews, including all the meta-natter that I'm putting into issues. Like, I'm four profiles behind schedule right now, and that's because, for the last few days, I've been up several hours past midnight spittin' proposals and cross-references and stuff like that trying to keep track of what I'm not recording. (I think just coming up with the WILDCARD solution took me up to 11 PM on Tuesday night.)

That said, previously I've let that stop me from working on this, and, well, this month it's my Project of the Month, so I'm going to stick with it, and I'll see what keeps popping up in the long term, and, well, we'll see.

@stuartpb
Copy link
Member Author

Okay, so, I've made pretty good progress on this so far (there are 25 remaining to be profiled, and, wow, I'm pretty sure that number was over 100 before I started), doing these reviews has given me a lot of insight into how the schema should be drafted, and I've hit on a really solid workflow for putting these reviews together in the future.

However, as much as I want to review the 25 remaining unreviewed profiles before the 28th, I'd rather spend the rest of this month closing out a bunch of the other remaining issues on this project, including splitting it up into separate repositories, and writing a proper schema with validation.

As such, I've decided I'm going to chump out and add reviewed dates to any remaining profiles that were added individually based on the timestamp of their first commit (or the last commit that meaningfully updated their information), and then only immediately review any that are still unreviewed after that. (A new issue can be opened up once this is done to review all the profiles that got retroactive review dates based on a "review everything before April 15 2015" filter, which can then be done post-February.)

stuartpb added a commit that referenced this issue Feb 26, 2017
Based on the time of their original commits, or earliest prior
commit. See issue #19.
stuartpb added a commit that referenced this issue Feb 26, 2017
Based on the time of their original commits, or earliest prior
commit. See issue #19.
@stuartpb
Copy link
Member Author

Okay, I'm merging this in now, as #280. (I'm holding back a couple profiles that I intend to either remove or move with review, as those will be separate PRs.) Every site that was added with its own commit (including everything after this project was first established) uses the date of that commit as its timestamp; every site that was added in the original blot.pw list in a monolithic commit adding multiple sites uses the date of the prior commit (as we can't know for certain that it was any later).

For reference, this is the breakdown of how the backfill dates were established:

Backfilled from domainprofiles commit

Backfilled from atomic blot.pw commit

Backfilled to 2013-10-22T06:29:22Z, committed at 2013-10-25T18:19:02Z

  • eventbrite.com
  • guru.com

Backfilled to 2013-06-16T01:33:52Z, committed at 2013-09-09T06:25:54Z

  • laptopscreen.com
  • digitalocean.com

Backfilled to 2013-05-30T17:41:28Z, committed at 2013-06-16T01:33:52Z

  • html5-ninja.com
  • twilio.com
  • projecteuler.net
  • wibit.net

Backfilled to 2013-05-06T11:07:47Z, committed at 2013-05-22T13:09:06Z

  • yahoo.com
  • linode.com

stuartpb added a commit that referenced this issue Feb 26, 2017
Based on the time of their original commits, or earliest prior
commit. See issue #19.
@stuartpb
Copy link
Member Author

Okay, now that #280, #281, #282, #284, and #285 have closed, all profiles have a reviewed field (as far as I know), so this issue, in its current form, can finally be closed (with the potential for a similar issue to be opened later).

@stuartpb stuartpb moved this from In progress to Wrapped / wrapping up in Migrations and Refactors on the Road to 0.1.0 Feb 28, 2017
stuartpb added a commit to stuartpb/opws-checklisters that referenced this issue Nov 14, 2017
None of these are relevant now that their respective issues have closed.
See opws/opws-dataset#4, opws/opws-dataset#70, and opws/opws-dataset#19.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

1 participant