Hack Nights should involve a high level of user engagement prior to the event. Events will be determined by suggestion and polling system that extends throughout the month. After the initial stage, ideas will move on to polling. (Ideas might involve multiple levels of polling depending on how granular the goal). The point of this is to make the event feel entirely member driven.

• First week of the month (5-10 days) suggestions come in
• Second and third weeks (10-15 days) ideas are voted on
• Fourth week of the month (5-10 days) we have the event up, decided on, event title is named with the hacknight in the title and updated to reflect the overall goal.

Hack Nights should be designed to encourage teaching and involving everyone. They should not only be designed to attract professionals and experts, but encourage newbies to attend, shadow, and jump in when they feel comfortable. Of course, Hack Nights should not be designed as ‘social hours’ (more on that later), so keeping conversation focused on the goal at hand is most important.

Be mindful of people poaching for startups not caring about the actual event. There is an expectation for participation. Setting short group norms for the event at the beginning (read it over at the beginning) you must follow the code of conduct, paired with the meetup invite. (cards in the deck).

Hack Nights should incorporate industry-standard tools (e.g. Trello, GitHub) used for collaboration. (This is what should be in your toolbelt). An important outcome of Hack Nights is to teach people valuable skills in teamwork. It’s almost expected to come out of a CS degree with little experience with these professional tools and mindsets, so incorporating them into Hack Nights can be highly valuable to those interested in working with others.

This might seem contradictory to the desired outcomes of the events, but Hack Nights are not ‘social’ events; they are goal-oriented events. Hack Nights should be separate from ‘mixers’ where members come to talk about work and life and should encourage active engagement in the pre-determined goal. This rule should be enforced based on discretion in a polite manner at the beginning of the event and in the event description (formed in a positive tone). We don’t want to shut down anyone from contributing ideas. It's a Hack Night, the goal is to engage and contribute.

Events should be hosted in a private setting in order to keep everyone focused on the goal. Coffee shops and bars are great for Byte Brunches and Social Hours, but in order to keep everyone’s attention, these events should ideally be hosted in a private environment. We might be capping the attendence for the first event in order to control the space, set up some initial requirements.

It is expected that Hack Night goals should take anywhere from 4-8 hours to complete. (Negotiable, needed for setting the tone of the event, not too short or too long for people to be interested). The time of the event can be voted on along with the goal, and time to completion is an important matter to voice an opinion on. Members should expect to be given enough time to complete a goal, so scheduling enough time at the location of the Hack Night is important. The events will most likely happen on the weekends.

After the first few Hack Nights we should send out a survey and continue to improve this document and create a structure which will slowly become a blueprint for other events. The first few events also may not follow the initial structure, the week after Spring break could be a good test run, planning around the academic calendar since we're trying to make this beneficial for beginners.