Internal memo

This is a memo I circulated within the Blueprint team around November to go over the many quality issues for the program.

What is this?

I’ve been going over previous reviews and I am noticing that there are a LOT of issues with consistency and a lot of not-so-great projects. I’m writing this document to set a precedent for what review is, why it’s important, and what should be changed.

Made by @alexren/dari/qcoral/whatever you met me as. Please ask any questions as they come so I can refine this doc as needed.

Overview:

First and foremost we are trying to get teens to build real, shipped hardware projects. We are not trying to get them to tick a bunch of boxes. What this means is that you must make your own judgement calls and understand the nuance of each situation. There is no formula for making a shipped project.

Review is also not a magical pass-fail system. It is ultimately an act of mentorship, teaching, and community interaction. Many of these people look up to you. Treat it as such. Be kind, be there, and try to remember what it was like building your very first hardware project.

Internal Justifications:

Every project should have an internal justification. It doesn’t have to be fancy, but it does have to hold up to scrutiny. This means that someone should be able to read it and understand why a certain decision was made, i.e:

I’m demoting this project down from tier 3 to tier 4 as I don’t think it meets the requirements. It’s a really simple build that only has a small simple pcb and a basic case, and overall it’s really similar to a hackpad.

Or:

Approving these for the requested tier. It seems generally consistent with the other projects in this category, in particular the case is pretty detailed w/ press-fit snaps and patterned designs!

If you asked for help to judge a project, make sure you mention them!

A copy pasted message does not work unless it has proper justification for being copy-pasted. For example with highway, for the final stage I decided to drop per-journal deflations. Here was the hour justification behind that:

This is a highway project that was reviewed by either @alexren, @acon, or a hack clubber.

a final pass for being shipped was given by @alexren. any issues should go to them hours are justified via journal.

projects between 15-30 hours get a flat 25% deflation rate. This rate was determined based on historical intuition & data experience reviewing 400+ highway projects, 400+ hackpads, and 50+ infill projects. All ~120 projects submitted so far with the journal system have not had integrity issues, so this is being extrapolated to future projects.

This is a justifiable extrapolation because highway is a short-term program of 2 months, and so quality drift is highly unlikely. Furthermore, it is almost impossible to get enough context to reasonably make more accurate guesses with our current collected data. This is a compromise so that we can move on.

any issues should go to @alexren

This justification (for the hours) works because it clearly states how the number was calculated, and how its data-driven nature makes it valid

This justification could have done a lot better in terms of keeping a paper trail of who did what reviews, but we didn’t capture that data until later in the program unfortunately.

In general, do not use copy-pasted messages. You will not have the data to back that up

Internal justifications are exceedingly important because they allow you to keep a paper trail of why certain decisions were made & by who. Especially as programs scale it’s important to be able to keep track when we inevitably run into edge cases & errors.

Feedback for users:

This similarly is also very important! Review is not a magical black box that says approved/denied. It is a system you send your project to to get feedback from community experts.

The most valuable thing that these programs provide is community, by far. Without any sort of social motivation then one’s desire to make these projects drops to zero. Make sure you provide that tangible human aspect!

Feedback doesn’t always have to be critical; if their project is good, then just give them a compliment! The actual specifics don’t matter too much, what’s important is that you mean it.

I know it can seem like a lot, but the extra 10 seconds you spend typing up that message will mean so much more for the person involved.

Other bits of feedback: Please make sure that the READMEs are actually parseable. I’m seeing many with typos, completely messed up tables, etc. CHECK THE REPOSITORIES