List of attendees.

[martinheidegger]

It would be good to have a list of attendees through the CLI

[iancrowther]

can you expand on this?

• what is the goal of having attendees via the CLI
• is this better suited to the gitevents-tito module?

[martinheidegger]

"what is the goal of having attendees via the CLI"

This has two purposes.

1. Better formatting I have to get the RSVP lists for events (sometimes the entrance is restricted). Those RSVP Lists by <insert-provider-here> are often not optimized on paper amount. I need to reduce the size often and do manually adjust the list (for example: sort them by name or group them under the starting name for better searching by volunteers.
2. Combined RSVP Lists If I can get the attendee list through this API it could give me the combined attendee list some time in future see Multiple signup-pages core#147

"is this better suited to the gitevents-tito module?"

No. As mentioned before I would love to have this for every provider. Also the cli allows further processing (bash scripts)

Note: In relation to #3 : Command line tools like to process line-by-line. It would be good if the tool would give the output as csv with headers as an optional flag (default: true)

[PatrickHeneise]

There's an RSVP list through ti.to, it would be great to get that data somehow from them and just pull it on the website as a widget.

Another idea would be a gitevents-attendees module which handles attendance and when you click 'Join' you get added on database/meetup/ti.to/alltheothertools.

I don't think it should be in the CLI (something that only runs once to set up the project)?

Or did I get this wrong?

[martinheidegger]

@PatrickHeneise We are talking about different things I fear. The RVSP list is mainly for the "organizers". This task is usually run at a different time than "setup" but it still is run mostly just once (before the event to print the attendee list)

Regarding "gitevents-attendees; click to get added": It is impossible to make sure that the user is logged in to all platforms and many platforms have user-requirements (you need to be logged-in to sign-up).

[PatrickHeneise]

Ok, that makes more sense, my bad.

I think that should be in the responsibility of the plugin (meetup/ti.to/facebook ...) to retrieve a list of attendees (we're using multiple tools at BcnJS, would also be great to eliminate duplicates etc.)

So far I'm happy with the 'check-in' functionality at ti.to though (it's still beta, so you might need to request access)

[martinheidegger]

Good that we are on the same page. Of course the plugins have to provide this data & eliminating duplicates would be awesome but I can also see this as a possibility to combine the date with a "crm"-like tool that adds other information if we have it. i.e. the fb page, photos, previous attendance whatever.

Sidenote: I have to print the list at some venues not for the check-in but for the entrance (only people written on the list are allowed to enter)

Other Sidenote: The lists functions as a sort of "proof-of-event" which is particularly important for free events that build on reputation.

[PatrickHeneise]

@martinheidegger ti.to does that with the checkin list. I requested a version from ti.to without email addresses and personal data some weeks ago and it has been implemented immediately. Very neat feature :)

[martinheidegger]

Yeah, I don't use ti.to :)

[PatrickHeneise]

You should :P

Ok, but that makes sense then to put this functionality in a plugin. Depending on what you use, there are API-ways to query meetup.com/ti.to etc. and get the list. You could provide a GET endpoint (/attendees) for example to retrieve the list, protected by some authentication?

[iancrowther]

@PatrickHeneise @martinheidegger so should this be in a separate plugin?

[martinheidegger]

The plugins have to support it but it should be part of the cli

[iancrowther]

@nnevala ^^

[PatrickHeneise]

I disagree. The CLI is supposed to give a head start on the setup, nothing else (and can be substituted with a neat HTML form later that just generates the json config). I want to prevent the CLI becoming too important (like "Hey, we have a CLI, we could also set up events through that instead of GitHub") - CLI isn't user friendly to non-techs - and gitevents should be for everyone. You can create a plugin that listens on /attendees with auth0 authentication for example and this attendee plugin should be able to load (and merge) attendee lists from meetup, ti.to etc.

[nnevala]

Yep, this functionality has to be driven by the core, and if it's exposed by the CLI it's just about querying the core for this data.

Ahead of actually implementifying this I added the support for querying the RSVPs to the Meetup plugin (gitevents/gitevents-meetup#9).

However, it now turns out that the Tito v2 API doesn't actually support retrieving tickets just yet, so I guess that's parked for now. (Or alternatively we could roll with v1, but the work for porting to v2 has already begun...)

[nnevala]

Just as an update in case someone picks this up later, Tito v2 API now has an endpoint or tickets: http://teamtito.github.io/tito-api-docs/#tickets