Skip navigation

Selection Criteria

This Group is archived. You may not add or alter any of its content.

Selection Criteria

We will be bringing on our first round of teams for mentoring in June. How will we select these teams? I'll get us started:

  • Solid skill set : examples of previous work
  • Work well together as a team (how can we tell?)
  • Code on a public repository : committed to open source ideology
  • Connects to other resources:
    • Worked across cities
    • Continued development on existing tool
    • Uses existing infrastructure in a new way

What else?

Comment viewing options
Select your preferred way to display the comments and click "Save settings" to activate your changes.


I think we should hear your specific goals very clearly before we figure out how to achieve them. I'll try a straw man and the rest of you can correct me. Typically, the single question that we (as investors) should be answering is: "What can we do for this team to make them succeed in business?" The implication is that our investment (of energy, money, social connection, time, etc) will be increasingly valuable. If that's the goal, then I think our feasibility criteria would have to follow a fairly traditional venture format: - Size the market - Model a profitable arrangement of inputs and transformations for production - Differentiate each team's idea from "how it's currently done" - Compare team experience versus idea complexity to establish a technical risk measure - Gamble on the team(s) with the clearest differentiator, lowest risk, largest market If there are issues that we would negotiate away for the right team and product, then we shouldn't include them in the selection process except perhaps as tie breakers. If an issue is non-negotiable, perhaps open source consideration is an example, then we should simply dictate that teams will be disqualified if they submit nonconforming plans. So maybe a three stage process? Qualification - do they meet all of the mandatory criteria? Feasibility - will the project be sustainable? Selection - ranking according to softer criteria Do we have an idea for how much money we'll be able to put into these teams? Could we leverage grad students? Maybe give them an additional stipend to develop their theses? We could treat it like a very low risk low cost team and be there to help transition the technology once the student is ready to move on, or at least to help distribute and popularize it. Just my 0.4 nickels.


Riley, I think these are really good points. We know they will have good intentions, that's why they showed up to the hackathon. Can they deliver and execute in a way that also responsibly supports themselves?


  • Prototype completed
  • Business plan
  • Understanding of existing platforms/tools
  • Understand customer base and how they might interact with them
  • Listing of competition or potential partners


  • What would the other uses for this tool be? ("good" and "bad")
  • What skill sets are needed, and how does that overlap with your team?

Selection: We could go for the Awesome Foundation method - people apply, each board member ranks at least 2 projects with a "1" - absolutely would love to support this; 2 "2"s - maybe with more work, or another time; and 2 "3"s - absolutely against this. A fair number of applicants aren't ranked, but it means the conversation we have is just around the extremes.


My only concern about this is that people will feel like they should do this stuff during the hackathon. We then become startup weekend for nice guys instead of focusing on project dev and having people go 'hey this is a business!'. Maybe I missed something though. -- Aaron Huslage sent via mobile device


The video is submitted by June 10th - which means they can work on the project during the event, and developing a business model afterwards. Or visa versa.


Slightly OT, but let's make sure to discuss submission process and copyleft/right issues before GWOB starts accepting others' IP.

On that vein, I appreciate the transparency mission of the atrium tool, but it is unclear to me how much of this is publicly accessible.  When we get the point of discussing which projects to engage, there is some benefit to closed sessions.

I don't want to sidetrack the thread with these non-mission issues, but I also don't want to get ahead of ourselves without establishing mechanics/containers.


Joshua, good points.

I have no idea where to start on the copyleft/right conversation - is that something we can talk about on May's call? I'm also hoping to firm up the process of accepting projects on that call.


One thing I think we should consider is the difference between "how successful will this team be" and "what is the delta in their success that we can make" -- I don't know how often this will come up, but clearly we should be focusing on teams where not only the team/project can be successful, but also where our assistance can make a real difference.


Take a look at this, let me know if it suits:

We should be able to pull together a good group based off of these criteria.

Please sign off or tweak and asign to the next person.

Need help?


The blog lets your team communicate by posting updates and discussing issues. It is a great place for sharing progress, discussing challenges, and exploring ideas.