Vice Chair

Author: Sumner Evans

The official role of the Vice Chair is very nebulous. Basically the only official responsibility is to help the Chair, and do what he says. In this document, I will describe what I actually did, and how I executed this office this year.

In general, the following were the main responsibilities that I carried out this year.

Organize tech talks.
Ensure that new attendees to project meetings were able to get up and running on a project.
Ensure that projects were being worked on, and that each project had an owner.

I will address each of these in turn.

Organizing Tech Talks

The first thing I did was figure out which days to have tech talks. We planned for a talk approximately every other week starting on the third week of school. (There is no ACM meeting on the first week of school, the second week of school is an intro to the club, and then the third week is when we had our first talk. For the spring, we didn’t start tech talks until late January because of the C-MAPP event being so close.)

Then, I put together a list of companies/people to invite. These are the companies I reached out to:

Google
FAST
System76*
Can/Am*
Pivotal*
Tyler Tech
Alarm.com
Kenzan*
ListenMD*
Gogo
Nasdaq
Mozilla*

* = not a C-MAPP sponsor

Then, starting during the summer, I contacted each of the companies and invited them to give a tech talk. For the C-MAPP sponsors, I asked Tracy to contact them, but for the non-C-MAPP sponsors, I contacted them directly. Here is an example email that I sent to Bill from Kenzan:

To: Bill Schwanitz <bschwanitz@kenzan.com>
Subject: ACM Tech Talk

Hi Bill,

A few weeks ago, you expressed willingness to give a tech talk at a meeting
of the Mines ACM this school year. This email is a follow up on that.

**TOPIC**
We had specifically discussed a tech talk on microservice architecture
covering similar content to what you explained to me and Jake. If you want
to discuss some other topics as well, that is perfectly fine. Below is a
list of the broad categories of topics that I've given to other companies:

 - interesting technologies (cool/new/trendy or tried-and-true)
 - software development processes and tools
 - general demystification of industry terminology and/or processes
 - talk on Open Source (e.g., how to submit or why OS != free labor)

Again, covering something other than microservices is optional. (And I think
that talking about microservices falls under a lot of the above categories.)

**SCHEDULE**
The tech talk will be on a Tuesday at 6:00 PM on the Mines campus. (If
Tuesdays do not work at all, we can schedule a different day of the week,
but Tuesdays are preferred.)

The target length for tech talks is 1 hr with time for questions after that.
Pizza (or some other food) will be provided at the meeting.

We are looking to fill the following dates with tech talks this Fall
semester:

09-19
10-03
10-31
11-14
11-28

We will also have openings for Spring, so if none of these dates work, or
you just want to wait until Spring to give a tech talk, that's fine too.

**OTHER LOGISTICS**
The head of the CS department, Tracy Camp, wants to meet all of the people
giving tech talks at ACM. (Not for screening or anything, just to get to
know them.) Once we set a date for a tech talk, we'll schedule a time for
that meeting.

I will also need the title and topic of your tech talk a week or two
beforehand so that we can advertise and get people excited!

Thanks again for your willingness to do this, I'm looking forward to hearing
a tech talk from you!

Thanks,

Sumner

The general flow of how I did this worked was this:

Contact company (either through personal connections or through C-MAPP/Tracy)
If they were interested, send them an email with a list of general topics that we wanted talks on, potential dates, and some basic logistics.
Respond to any questions they have, back and forth emailing.
A few weeks before their talk, I contacted the company to get a talk title, and confirm the speaker.

Email the officers, Kelly, Tracy, CPW, and Shannon to get the ball rolling on advertising the talk. Here’s an example of what I sent out:

To: Jack Rosenthal <jrosenth@mines.edu>,
    Sam Sartor <ssartor@mines.edu>,
    "Dr. Tracy Camp" <tcamp@mines.edu>,
    Christopher Painter-Wakefield <cpainter@mines.edu>,
    Kelly Knechtel <knechtel@mines.edu>,
    Shannon Martin Roebuck <sroebuck@mines.edu>
Subject: Google Tech Talk

Hello everyone,

Here are the details for our next Tech Talk Tuesday from Google:

Date: Tuesday, 27 February 2018 at 18:00
Location: CK 140
Company: Google
Title: Writing Good Code
Presenters: Paul Christopher

RESPONSIBILITIES:
* Kelly: Please add this tech talk to the next few CS Weekly emails
* Jack: Please do your flyer magic :)
* Sumner: Submit to Daily Blast
* CPW: Once Jack finishes the flyer, please share it with the rest of
  the faculty
* Shannon: Once Jack finishes the flyer, please print and post around
  Brown Building

If anyone needs any other information, please let me know.

Thank you,

Sumner

Submit the tech talk to the Daily Blast. This is done at https://webapps.mines.edu/DailyBlast/Home/BuildDigestItem. I used the following settings:
- Department/Organization: Mines ACM
- Category: Campus Events / Meetings
- Audience: Faculty / Staff and Students
- Division: Student Life - Student Activities / Organizations
- Title: <company> - Tech Talk Tuesday - <talk_title> - FREE FOOD!
- Brief description: Join Mines ACM as we host <name> from <company> for a presentation about <topic (can be longer description than title)>.
- URL: https://acm.mines.edu/schedule
- Check the box to disable the long description, and instead go straight to the URL.
Make sure that the talk is included on the Daily Blast on Monday and Tuesday on the week of the talk.
A day before the talk, send a short email to remind the presenter and offer to answer any last minute questions.
A day after the talk, send a short thank you email to the presenter.

What Went Well

We had a lot of companies with a wide variety of talks.
We had quite a few really great tech talks (ListenMD, Kenzan, Google, Nasdaq) and some pretty good ones (FAST, Gogo).
Our advertising processes worked, attendance at talks never dipped below 20, and got up to over 60.

What Went Poorly

A couple of the talks were bad (Alarm.com, System76)
Some of the talks were not on very specific topics (Gogo)

Suggested Changes for Next Year

Don’t invite Alarm.com. If they contact Tracy for some reason wanting to give a talk, say that Mines ACM is not interested in hosting Alarm.com for a tech talk, and that we will not put our brand behind the talk. This is a possible situation, because, as C-MAPP sponsors, one of the perks is that they get the opportunity to give a talk at Mines. It’s fine if they do a C-MAPP sponsored event, but I highly recommend not putting the Mines ACM brand and advertising power behind an Alarm.com talk.
Request talks that are a deep dive in a single topic. (DFS rather than BFS)
Don’t confirm tech talk date until you get a topic, and description of the talk. We started doing that this spring to avoid any more Alarm.com talks, and it helped provide some pressure on presenters to give us better, more technical talks.

Important Notes

Companies are slow. Start this early! I’d set up all of the talks for fall semester before the beginning of the year. I was not so proactive for spring, which made it a bit more stressful.
Make sure that you keep Tracy, CPW, and all the officers in the loop on what’s happening.
Tracy keeps a spreadsheet with all of the CS department events. We have been using that to try and prevent scheduling conflicts with ACM/LUG/C-MAPP/etc. events.

Onboarding New Attendees

The main thing here was identifying new attendees, and then getting someone (a lot of times it was me) to help them get up and running on a project. If they are new to working on software engineering projects in general, make sure that they learn the basics of Git, GitHub, etc.

I think we did decent job of this, but we didn’t do a great job, because a lot of people who came to one meeting seemed to get information overload, and didn’t come back next time.

Also, it sucks having to do this every meeting because you can’t get any work done, so I suggest that you set up some system where you have a rotation of people who are willing to help onboard people at every meeting. This will be a good way to get other members of the club experience in this process, as well as free you up for more important tasks.

Manager of Project Ownership

This is something that I didn’t really start doing until late in the year. After Sam and I discussed what made a project succeed or fail. I think this way of thinking about club/project/issue management is useful and worked pretty well in the little time we’ve been doing it so far.

The main difficulty here was identifying who had stake in a project, and making them the owner of it. For example, with Visplay, Sam started out as the owner of that, but Robby did a great job of running with the vision for that project laid out by Sam and myself. He effectively “owned” that project. Note that ownership does not imply that you cannot delegate, and it does not imply that you must be the owner forever. The idea is that at any given time, there is someone who you can point to and say “they own project X, go talk to them if you want to work on that project”.

On the first day of ACM, I recommend making sure that any project that people propose has an owner. This will help ensure that people (especially project owners) feel like they have stake in the club. If at some point the owner of a project decides that they don’t want to own it anymore, find someone else, or if nobody wants to step up and own the project, disband it. Projects without an owner are worse for morale than dead projects because you have people sitting around trying to figure out what to do (Indians with no chief, so to speak). Additionally, within in each project, it should be clear who owns what tasks.

Tip

If you have any questions or want to suggest a change to this document, please submit an issue or PR to the GitLab repo.