Remove last year's users from all of the event groups if we are still using the same event nodes

[mirie]

Many of the og groups have last year's attendees. We need to remove them if we are going to be using the same event nodes.

Example: http://nyccamp.org/group/node/423/admin/people

We also need to update the document the process for granting a group organizer the correct permissions as the process is very confusing and tangled up in permission problems.

[jonpugh]

Let's not re-use old OG-ified event nodes.

My gut tells me that we should limit the group organizer's permission to simply view the list of users that signed up. I don't see any other use case for the event's author for now.

[ForestMars]

+1 We should definitely not be reusing last year's event nodes.

Is everyone clear on how COD/OG works, and how it allows a single continuous site to operate year-after-year for all your events? This gives a great camp history.

As for group manager, aka event organizer, they need to mainly be able to do 2 things:

1. See and contact all users who have expressed interest in a given event
2. See and contact all users who have RSVPd for their event.

[mirie]

Ok, well there's some confusion here already then in the group.

We are already reusing last year's event nodes. Summit Organizers were told to update the descriptions of the existing published nodes.

An Example is the Publishing & Media Summit, http://nyccamp.org/node/28, originally authored on: 2013-06-02 00:49:51 -0400

The Community Tools Workshop, http://nyccamp.org/node/87, originally authored on: 2013-06-08 18:05:39 -0400 is another example.

[jonpugh]

hmm good point. I didn't realize what you were referring too.

Last year the "event signup" was incredibly inconsistent. I think we should consider removing all of that. I can see a need for trainings having signups, but other than that I'm not sure it was all that helpful.

Can we "ungroup" those event nodes, thereby removing all members?

[ForestMars]

@mirie Yes, that is clearly wrong. Can we just revert to the previous revision, and add nodes for this year's events?

@jonpugh Well, signups are incredibly helpful- what was the inconsistency? I would say definitely not to ungrouping nodes.

[mirie]

@ForestMars,

Update: This was discussed during last night's meeting. We will continue to use the current (last year's event nodes) for this year's camp.

[ForestMars]

Sorry I had to miss last night's meeting, but I'm afraid we're going to have to revisit that, unless someone is volunteering to fix it, and can provide an eta / deadline when they will have it fixed by.

[ForestMars]

I'm not sure what was discussed on the call last night, but just reviewing this thread, what I am seeing is "we already started doing it wrong, so let's continue down that path."

I've not really seen a lot of success stories come out of that approach.

I also want to re-emphasize that any development decisions that come out of conversations, be they formal meetings or hallway sidebars over beer MUST be documented and reasons clearly articulated .

I've gone ahead and fixed the problems in this issue, so I think we should be able to kill the "already doing it wrong so keep going" argument. Thus this issue looks closable to me.

[willykaram]

Forest I don't agree with the intepretation of the thread. As "we already started doing it wrong". I'll post my interpretation or what we discussed on the call last night.

[willykaram]

@ForestMars @mirie For starters, WRT to reusing the nodes. I agree that on a year-over-year site, we should not be re-using event nodes from 2013. However, we haven't architected this as a year-over-year site, and we most certainly didn't do that on the 2013 (which was pretty rough to get out the door, but we did than to some great effort). That said, we did use the 2013 site as a base to start the 2014 site. And given the time pressures that we're facing and that the camp is officially about 36 days away, right now we just need to focus on getting it done. So if re-using the nodes save time, we should do so.

[willykaram]

@ForestMars @mirie WRT to the broader issue of whether we're "doing it wrong". I think the more accurate issue is whether we're adhering to and supporting COD roadmap. With regard to that issue, I think the answer is "yes", and more specifically that 2014 site we are aiming to lay the tracks for continuing to use this site for 2015. If we succeed in doing so and can use the site for 2015 as well, then we will likely be the first camp do to so, and hopefully continuing or aims of helping lead/contribute back to the Drupal community. That said, if we are going to succeed in going down that route, we MUST document our plan for doing so. In particular, we must document how were dealing with functionality relating to event registrations (i.e., registration entities) and 'expression of interest'/'keep me updated' (OG). We must also document how were dealing with mailing lists, themes year over year, and most importantly the overall UI and navigation for hosting the content for 2 years of camp content on the same site. Frankly the UI issues are probably most important as community members are going be expecting a traditional camp site (which are one year sites), and we're going to be doing a first. So while I think it's great to go this route, we should have a documented, and not try to (a) do it on the fly or (b) not try to do it retroactively for the 2013/2014 content, but rather only forward looking for the 2014/2015 site.

[ForestMars]

Right, we're totally on the same page here, as we have discussed. The doing it wrong comment was a reference to seeing the 2013 site cloned, and then a less than organized effort at scrubbing the content, when all that was really needed was an hour or 2 to add the new events for this year.

And yes, also as discussed, the goal here is to be the first camp to correctly implement the COD roadmap, that is, to have a single camp site, on a single domain, that can be updated each year to add the new/annual event. In case there is still anyone who doesn't know what that means, it doesn't mean editing last year's nodes to have this year's descriptions, which really would take as long as "doing it right" - adding the new nodes for the new year.

Currently then, the site has all the nodes from 2013, which have "2013" appended to their node titles, so it's very obvious, and additionally, they are temporarily unpublished, as an added precaution against any potential confusion. And of course we have all the new event nodes for this year.

The 3 remaining issues are:

1. Configuring and testing the conference node type to be the default group into which 2014 content (ie sessions) is/are published. There should probably also be an entity ref on each of this year's events, set to this year's conference node as its default value.
2. Cleaning up the implementation of event registrations vs. group subscriptions, which definitely needs to be canonically documented. (instead of a mix of irc, skype & github.)
3. Implementing camp/event registration in the UI, so that both new and returning users can register for this year's camp as well as any of the events (trainings, sprints, summits, etc.)

There are also some related issues which need to be documented, for example how do group managers message group subscribers? (Currently they can message event registrations via OG broadcast, but we've been using Mailchimp to message group subscribers.)

Issues that have been brought up but we don't wish to tackle (out of scope for this year) include whether the group subscriptions shouldn't persist year to year (I agree they should) with only the event registrations changing annually. That way, a member of the DevOps summit group, for example, wouldn't have to join each year, but only indicate whether they would be attending. We may want to synch group subscriptions with SugarCRM, which would get us one step closer to insuring that the conversations which spring up at the camp aren't hung in the closet until next year, but continue to blossom and grow all year round. (This is out of scope for this year.)

The immediate priorities however are 1-3 above, which is mostly there, just needs someone to go in an test, and finish any remaining/missing config.

[ForestMars]

Having said all that, this issue can be closed, since we do not need to remove last year's attendees from last year's nodes. That's part the anti-pattern I was alluding to, as it erases our history.

The relevant discussion is taking place in #90. (Although there are some notes here in #64 that should be moved to the canonical document.)

[willykaram]

@ForestMars As per your my discussion earlier tonight agreed on all points. Thanks for the well documented summary/plan.

[willykaram]

@ForestMars As an aside I signed up admin@nyccamp.org for the Sugar subscription that we previously discussed and am going to be inquired about a free/discounted subscription. We can ideally use that for the purpose mentioned above as well as managing featured attendee/sprinter attendance and sponsorship.