Some Thoughts

[Brandon Mason]

So first off, I contacted Terry at the Burton Barr Library to ask about us using the space.  I'll post here when I have a response.

I watched the video that Andy had posted a few weeks ago on teaching/starting a Clojure group.  Cool material, and I have a few thoughts about where we might take things:

1. The group should be about shared exploration - ditch the student/teacher dichotomy.
2. Members should work to help each other understand concepts.
3. A culture of respect - ignorance is an opportunity not a crime.
4. Leadership - encourage 
5. Unless there's a predefined event (guest speaker, workshop, etc.), begin the meetup with an agenda-forming discussion.
6. Activity categories:
1. News (new tech, business, hiring/seeking)
2. Lecture (by request or submission)
3. Code Review/Refactor (come with some code that you'd like to take through the process)
4. Workshop (some prepared materials that will walk us through a process)
5. Discussion (high level problem question, perhaps from work, perhaps regarding people's technology preferences)
6. Meta (discussions about the group itself)
7. Always leave time for networking/bullshitting (should we do this before or after?)
7. In addition to the in person meetups, questions/discussion should be welcome on the mailing list.  We should consider doing an IRC channel or something as well.  (Maybe something encrypted?)

The end goal of all this is for the group to remain adaptive to the member's needs, to not exclude anyone regardless of their background, but to be structured and productive so we're not wasting peoples' time.

Within the video they proposed a problem solving process:

1. Establish a goal
   
2. Define fundamentals required
   
3. Teach fundamentals individually
   
4. Integrate to address the goal
   
5. Generalize the solution
   

I think that's reasonable to follow.  It will take some time but will give an in-depth analysis.

One of my disappointments with meetups is that often subjects I'd consider important don't get attention, or they happen late in the agenda after people are leaving.  I think it's a missed opportunity, and that's what I'm trying to address with a little up front discussion of agenda.  It also clarifies the schedule early on so people are not wondering when will be a good time to leave.

We should have a clear process for the agenda so it moves quickly and people aren't confused/disgruntled about the results.  We should also establish some guidelines around all the categories, so that we keep things moving.  We don't want someone to monopolize the floor or start an activity that's going to take the rest of the night.

I think we should document this stuff, but it doesn't have to be done all at once.  We can grow it over time, and as the situation warrants.

Please feel free to discuss/argue/meme drop.

Best wishes,

Brandon

[Brandon Mason]

Looks like we are 'go' on the library space.  Still working out the details, but they are receptive.

[Andy C]

Awesome write up. My first thought was, let's not loose it. And  I see that:

>I think we should document this stuff, but it doesn't have to be done all at once.

IIRC the clj-phx had a github repo, pehaps we could use it, create a repo just for markdown based docs.

Andy

​

[Brandon Mason]

I mainly use Google Docs for documentation within my business.  I think that will work for brainstorming, until we get to a phase where we want to publish for a broader audience, then we can look at a solution involving markdown/static website generation.

--
You received this message because you are subscribed to the Google Groups "clj-phx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clj-phx+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.