I don't know whether this is a description of how we'll collaborate or a proposal. Maybe somewhere in between.
At any rate, this is up for discussion, so if you don't think something is going to work for you, speak up.
1. We'll use a shared repository for the code. My preference is BitBucket and Mercurial, but if somebody refused BitBucket, I could probably be talked into GitHub and Git. With BitBucket, the maximum team size before needing to pay for it is 5 people. But with a 1-day event, I can't imagine being useful with more than 5 people anyway, so if we hit that limit, we split into two teams.
2. I can do Mercurial/BitBucket training via Twitch on Friday if people want a crash course. I do also have tutorials. I know a lot of people around here are already using Mercurial and BitBucket, so I won't do this unless people ask.
3. We can talk via the chat room during development.
4. I'd be open to a voice chat server, but I know that doesn't work for everybody, and the last time we did that, we, er, uh… got kicked out. So I'm less inclined to go with this approach, but if somebody wants to make it easy for us, I'd join in, personally.
5. We've usually made a design document using Google Docs. It works really well for outlining our plans. I'd suggest we do it again.
6. I'd love to find a "shared whiteboard" system somehow. When I'm doing development, I have two whiteboards (one on the wall, and a smaller one on my desk). It's great for drawing out things. Perhaps there's a free Windows Store app (did you guys upgrade to Win 10 yet?) or just a website that we could use. I don't know what it would be at this point. Maybe I'll do a little research. At any rate, this would be intended for short little side discussions (design, etc.) that need something more than just text.
7. While we've never tried it, I might also be interested in managing the things we want to do in something like Target Process or Trello. Trello is definitely lighter weight. I like Target Process much better, but perhaps Trello is a better fit for this sort of thing. But maybe the Google Doc is good enough.
The other thing I want to talk about here is to start a discussion about how to deal with the initial stuff. It seems like the problem is, we can't just easily jump in without stomping on each others' toes. There's not much stuff that can be shared right at the very beginning. And in the past, that meant spending an hour or two up front with everybody waiting for somebody (me) to get enough put together that they can pull down the repository and start making their own changes. It's bad for everybody, because it's wasted time, and it's bad for me, because the pressure falls on me to get the design done (a) correctly and (b) quickly.
I don't know the answer to this, but here are a few options:
1. We decide on a game early. Perhaps by Wednesday night. That gives us two evenings (or mornings or whatever) to start brainstorming what we want to do and how. That puts us in a position where we might have enough in the way of boundaries between the various pieces thought out that we could actually simultaneously start development at the beginning.
2. We have an optional 1 or 2 hour session in advance of the 8 hours where people who are particularly interested in this upfront design/architecture can work together to get it right. (Basically pack #1 into a 1-2 hour thing just before the collab.)
3. Same as #2, but I just do it myself, rather than lots of discussion, and I stream it on Twitch and explain what I'm doing. Because there's no discussion among a group, ("I am not a committee!") I can get through it faster (probably 30 to 60 minutes instead) and because it's on Twitch, people can see how it all works in advance so I don't have to explain it all repeatedly. This of course leaves the unresolved issue of I'm doing a bunch of the interesting stuff without people, which I'm not a huge fan of. (It's a collab, after all.)
4. Of course the problem with the other three proposals is that the time starts to sink into other hours and even other days. So this option would be to do one of the earlier options in the first hour or two of the official collab, and just deal with it eating into our time. This is less of a problem if you think you might hang around for a while after the official 8-hour block ends.
5. Or… just make the competition 10 hours instead of 8. Personally, I like 8. It leaves time in the evening to go back to things you put off all day. And it's a full work day, so it kind of showcases what you can get done in a day of programming, if you have no distractions. (Honestly, I get way more done in these collabs than in a typical work day. It's sad but true.)
Anyway… I know that's a lot to digest. I'm open to other possibilities for both of these topics. Like I said, the sooner we can get the discussion started (and ended) the better. We don't have much time left at this point. (That's really my fault though for not getting the ball rolling before I left on vacation.)