Hello spaceappschallenge people,
here is my feedback write-up:
Here are my observations as global dispatcher/virtual op for the
spaceappschallenge from April 21st to 22nd 2012. The things pointed
out here are not all of the same importance.
- good things
- email itself
- using etherpads
- hosted shared spreadsheets for virtual ops
- challenge overview (hastags, etherpads etc.)
- linking cities
- having a virtual ops backchannel
- email-server was not't properly configured (possible non-delivery?)
- registration form stated "Required Field" if email was already in the system
- unstable pads during North American peak
- read-only place for static info
- better overview of supply and demand of skills
- wiki for virtual ops
- ticket system for virtual ops
- mailing-list for coordination upfront
Sending out emails with short "core" information was a good idea. People
seem to care for what will happen in the next 12 hours (at max), but not
much longer. Having the option of sharing each message on social media
was probably a good thing. I don't use facebook, twitter, google+
actively, so my insight is limited.
The email-server did not use/had a full qualified domain name (fqdn).
That leads to problems with restrictive server-configurations. These
servers will reject the delivery attempt and thus the email will not be
received. Here is a short excerpt from a postfix log file:
Apr 20 23:08:22 dropcut.net postfix/master: daemon started -- version 2.7.1, configuration /etc/postfix
Apr 20 23:10:11 dropcut.net postfix/smtpd: connect from 108-166-124-22.static.cloud-ips.com[126.96.36.199]
Apr 20 23:10:12 dropcut.net postfix/smtpd: NOQUEUE: reject: RCPT from 108-166-124-22.static.cloud-ips.com[188.8.131.52]: 504 5.5.2 <spaceapps>: Helo command rejected: need fully-qualified hostname; from=<firstname.lastname@example.org> to=<email@example.com> proto=ESMTP helo=<spaceapps>
Apr 20 23:10:12 dropcut.net postfix/smtpd: disconnect from 108-166-124-22.static.cloud-ips.com[184.108.40.206]
The server rejected delivery due to the following two options:
smtpd_helo_restrictions = reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname
They both are used to reduce Spam since exploited computers (e.g. PCs in
botnets). These machines very rarely are registered in the Domain Name
System (DNS), proper (stable) configured SMTP-servers are (e.g. in the
MX-field). The problem may be caused by using a cloud service (judging
from the log), or at least an inproper configuration of the smtp-server.
As a side-note: Twitter has the same problem.
This issue can be fixed by having the SMTP-server configured properly,
especially the HELO-command. This may be done the easiest by using a
dedicated smtp-server or a good (cloud) service. Setting up a SMTP-server
on a dedicated machine takes about a day for someone with a systems
administration background. Monitoring the logs during the contest makes
spotting this sort of problems easier.
The registration form had an issue with the email textbox. When registering
with an email-address already in use, the form replies with coloring the
box red and the text "Required Field". That misleads the user to think
that the email (itself) is not transmitted, while the real issue seems
to be duplicate data in the system. A message stating "This email is
already in use" (which leaks private data about already registered users)
or "please choose another email-address" would be a better way to resolve
The etherpads became quite unstable (especially during the North America
peak). This was most likely due to the software itself (from my experience).
This could be overcome by using/hosting less resource-hungry equivalents
like etherpad-lite. People went for pastebin. This approach could be used
for semi-static information which does not need to be updated frequently.
An example could be configuration files or things like that. In case
self-hosting is possible, zero-bin would be an interesting option in terms
Ideas and possible Improvements
Maybe the orchestration of email information could be tuned to timezones.
That in turn implies having this information for each participant. A more
simple approach is to use the earliest location to time the information.
This location should dictate the timeline and content of emails send out.
A central (read-only) place could be helpful for the following information:
- challenge overview (like we had in the spreadsheets)
This could be implemented by generating static HTML-files and serve them
(no need for fancy database or PHP stuff here). Tools like Jekyll can be
used for this.
The (inter-) dependence between projects should be pointed out. There were
challenges which (implicitly) depended on other to be solved earlier. Many
challenges relied on PDS data, specifically JPL HORIZONS. Making this
relation explicit could help people (and the staff) allocating resources
and prioritizing tasks. A possible way of doing this is a global dependency
graph and/or a local (sub-) graph for each challenge showing its prerequisites
and possible outcomes.
In case there is a date for the next challenge, point that out to people.
If the sponsors are willing, the participants could vote on a follow-up.
At least parts of the hosting can be done by universities and hackerspaces.
I believe they could be willing to do this, since it provides an excellent
opportunities to let staff collect experience with high-load application.
A marketplace for skill-sets (aka brain-dating) could be an option to get
people involved in the projects. Having a better overview of the supply
and demand of skills could at least help the virtual ops in connecting
people, or even help the community to figure it out on their own.
Maybe preference based voting (like in the Debian project) or even
recommendation engines are a venue to explore.
Setting up a mailing list upfront would be helpful for coordination. It
makes replying and filtering email easier.
The last two ideas deal with the virtual ops specifically. IT would be
helpful to have a small wiki for all the information that had to be
asked for in the backchannel. A ticket-system also could help to have a
better overview over what needs to be done for the community/the
virtual ops and the current state (like who is working on it etc.). There
are already numerous ticket/bug-tracking systems out there.
I hope this feedback provides some valuable insights. If there are any
questions etc. left, please get in contact with me at firstname.lastname@example.org .
* fdqn: http://en.wikipedia.org/wiki/FQDM
* SMTP: http://en.wikipedia.org/wiki/SMTP
* Postfix: http://www.postfix.org/
* DNS: http://en.wikipedia.org/wiki/Domain_Name_System
* etherpad-lite: https://github.com/Pita/etherpad-lite
* Jekyll: https://github.com/mojombo/jekyll
* homepage: http://sebsauvage.net/wiki/doku.php?id=php:zerobin
* source: https://github.com/sebsauvage/ZeroBin
* Debian voting system: http://www.seehuhn.de/pages/vote
If you need/want it in another format (odt, pdf ...) or have questions/remarks, please drop me a line.
So far from Germany,
Johannes Schneemann (hf/rylee)