Ideas on handling event requests

Community Portal Mozilla Kerala
#1

Hello,

The problem
As you know, if someone outside wants us (Mozilla Kerala) to organize an event for them, they need to send an email to events@mozillakerala.org. The process that is in place for handling event requests right now is not very efficient. Now just 2 people monitor the “events” email inbox and they respond to requests and personally organize the events themselves. As you can see, this isn’t a really good strategy if we want to scale.

Why are event requests important
Incoming event requests are important, because:

  1. Someone “wants” us to go to their place and organize stuff (as opposed to we organize stuff and ask ppl to attend)
  2. Shared expenses between MozK and host insitution.
  3. Better chances at meeting people who are currently not connected to us, rather than when we organize an independent “Mozilla Kerala” event and invite registrations.

Things to consider when looking for a solution

  1. We should have a scalable process in place
  2. Utilize the number of volunteers (old and new) that we have and give them an active role in handling event requests (from handling incoming emails to successful completion of events)

Please share your ideas.

1 Like
#2

Hi,
[I don’t know the etiquettes of replying here.]

How about making a custom cms type of website which fetches the electronic mails sent to events@mozillalerala.org
The advantage is that you won’t break the abstraction that users are already comfortable with.
Regards
Shrimadhav U K
https://github.com/SpEcHiDe

References
http://php.net/manual/en/function.imap-fetch-overview.php

#3

Thanks for the reply. Personally, I would much rather like it if we didn’t have an extra system (CMS) to maintain, much less develop a custom one.

And why do we need to fetch the emails from events@mozillakerala.org into a CMS? What is the goal of doing that (I think I didn’t understand the abstraction part)?

#4

I had proposed a model during community meetup 2015 which would make the process more open, but that has a lot of blockers that need to be solved before it can be used. I’ll just put it here though (along with the blockers).

The Proposal

Events Portal
This serves double purposes : events listing and event requests, both in the same place.
Have a portal at events.mozillakerala.org that lists past and future events of Mozilla Kerala. This portal will also have a form that would automatically file an event bug at bugzilla.mozillakerala.org.
The flow :

  1. User fills up an event request form on events.mozillakerala.org.
  2. bugzilla-events-daemon@mozillakerala.org files a bug at bugzilla.mozillakerala.org.
  3. User gets a confirmation email from bugzilla-events-daemon@mozillakerala.org with a bug link to track updates.
  4. Events module owners gets update email from bugzilla.
  5. Events module owners put the events up for discussion at the next bi-weekly meeting.
  6. During the bi-weekly meeting, someone takes up the event, assigns the event bug to themselves and contacts the requester for more info.
  7. The event happens!

Blockers

  1. bugzilla.mozillakerala.org outbound emails end up in the spam box.
  2. The events portal is nowhere. It’s just on paper (or rather on a Trello Board (the community meetup one) somehwere). There isn’t anyone ready to take up the task of building this thing and bringing it into reality.
1 Like
#5

Putting bugzilla to use sounds like a good idea. That is how Mozilla handles event/other requests, I guess.

Also, can we do without the portal? Just have a bugzilla installation where people can create an account and create bugs for event requests? Then assign people and stuff.

#6

Github issues, maybe? The advantages are that many people have github
account, all issues have more visibility, easier labeling, can have a
templated link to new issue.

1 Like
#7

Hi,
What I meant was a platform where the Mozilla community can see all
upcoming requests. Based on the member hierarchy , they can approve or
decline requests, respond to the person who requested the event, and other
such things.
In this case, the person requesting the event does not need to change his
workflow, and that was what I meant by breaking the abstraction barrier.
Regards
Shrimadhav U K

#8

Well, there’s that extra step of creating a bugzilla account for just one or a couple events. That’s why I suggested to have a portal. It would be useful in the future too.

We could try Github Issues like the Participation Team is trying to do. It would avoid the barriers of having to wait for someone to create something entirely new (though I’m still in favor of the portal proposal). Then again, there might be many people who’d still have to go through the sign-up procedure for just this purpose. That is a good thing though, they’d be open to whole new world of open-source and we can’t do anything satisfying everyone.

2 Likes
#9

I agree that github offers the least infrastructure overhead, but isn’t it a little too open? Event requests often deal with personal and financial info and I think it would be better if access to particular events are better off given only to the concerned parties (Again, similar to how the Dev Engage team/others handles event requests).

3 Likes