Skip navigation

Johannes feedback on virtual participation

This Group is archived. You may not add or alter any of its content.

Johannes feedback on virtual participation

Hello spaceappschallenge people,

here is my feedback write-up:

Spaceappschallenge Feedback

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

- issues

 - 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

- improvements

 - 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 postfix/master[15259]: daemon started -- version 2.7.1, configuration /etc/postfix
 Apr 20 23:10:11 postfix/smtpd[15276]: connect from[]
 Apr 20 23:10:12 postfix/smtpd[15276]: NOQUEUE: reject: RCPT from[]: 504 5.5.2 <spaceapps>: Helo command rejected: need fully-qualified hostname; from=<> to=<> proto=ESMTP helo=<spaceapps>
 Apr 20 23:10:12 postfix/smtpd[15276]: disconnect from[]

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
this issue.

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
of software.

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:

- timeline/agenda/deadlines
- 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 .


* fdqn:
* Postfix:
* DNS:
* etherpad-lite:
* Jekyll:
* zero-bin

 * homepage:
 * source:

* Debian voting system:

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)
Need help?


The notebook section provides a way for you to store and share information with your group members. With the book feature you can:

  • Add book pages and organize them hierarchically into different books.
  • Attach files to pages to share them with others.
  • Track changes that others have made and revert changes as necessary.
  • Archive books that are no longer of interest to the group. Archived books can be reactivated later if needed.