Q3 Engagement Survey - launch

TL;DR - Please complete the Q3 Engagement Survey!

We’re launching this quarter’s engagement survey, asking core contributors about the things on their mind. Our last engagement survey was in May 2019 (results here).

We’ll be using the same survey format in Q3 as in previous rounds. Your feedback will be anonymous (but shared back out verbatim).

Timeline

  • The survey will be emailed to you directly by 21st August.
  • Deadline for responses is 28th August.
  • We’ll share the results by 30th August.
  • Hangout will be on 2nd September.

Next steps

We’ll be sharing the raw response data as we’ve done for prior surveys; this quarter we’re also planning a follow-up hangout on 2nd September where we’re inviting everyone to bring solutions and bounce ideas with us. There’ll be debating and dot voting, so don’t miss it!

We’ll get to work on implementing the highest priority fixes straight away. Once we get to the Offsite, we’ll be in a more informed place - armed with feedback, solutions, and network data, and so we’ll be able to make much more focused use of the time there to consult on proposals for team improvements.

Beyond this survey we’ll soon be kicking off the relationship network mapping exercise which you may have heard about in this week’s Town Hall. Watch this space for more info coming soon!

Questions? Drop them here.

Thank you!

5 Likes

I don’t see any survey email in my inbox.

Check your spam folder, mine was there, maybe worth notifying people? might not be the best start for an engagement survey :slight_smile:

Hmm indeed, something about the origin…

Thanks for flagging!

Have followed up in the #status-peopleops channel, and we’ll add a note in this weeks’ newsletter too. If anyone has any problems, please ping!

What service are you using to send the survey? We might have to update our SPF record to make that work. Right now we only have rules for Google(naturally) and extra for GreenHouse added:

 $ dig +short TXT status.im | grep spf
"v=spf1 include:_spf.google.com include:mg-spf.greenhouse.io ~all"

You have to realize that you can’t just offload sending out emails from someone else’s infra without appropriately adjusting security settings - like our SPF record - to allow that to happen.

If we didn’t block stuff like that it would be too easy to spoof our addresses and do some nasty phishing. Next time you intend to send emails from some other service than Google or GreenHouse you have to contact me, or the emails will end up in spam or never get delivered.

Thanks for clarifying that @jakubgs . I hadn’t realized this could happen, but is also relevant for me. I ocassionally send out emails through other services to research participants. Always try to minimize use of email and primarily use Qualtrics, but I wouldn’t rule out other services. Will let you know in the future.

One weird thing for me is that the current rule in our SPF record should have covered the survey email, since it came from trix.bounces.google.com:


And if I query if for TXT records:

 $ dig +short TXT trix.bounces.google.com     
"v=spf1 redirect=_spf.google.com"

We can see that it redirects to _spf.google.com, which we can see as already included:

 $ dig +short TXT status.im | grep spf
"v=spf1 include:_spf.google.com include:mg-spf.greenhouse.io ~all"

So I’m not sure exactly why the Engagement email ended up in SPAM.
I will have to do some more research on this. @ceri could you send a test survey just to me so I can investigate this? Contents are irrelevant, I just want the email.

Look at the raw email (“Show original” from GMail’s three-dot menu) and you’ll see a DMARC failure:

ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass [email protected] header.s=20150623 header.b=bbUwsGQl;
       spf=pass (google.com: domain of [email protected] designates 209.85.220.69 as permitted sender) smtp.mailfrom=3RPNcXQQJBo8vxA1BCtCDB.15BCxyt6BCtCDB.15@trix.bounces.google.com;
       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=status.im

Right, but that makes no sense. DMARC informs mail servers what to do with emails that fail verification based on SPF and/or DKIM records, but both of those passed, as we can see in what you posted, so why was quarantine from DMARC triggered? Makes no sense to me.

Could be this: email - DMARC/SPF/DKIM not authenticating with third-party mail - Stack Overflow

Yes, you might be onto something. I might try poking Google support, because it’s pretty silly that their own survey system can’t send emails properly via domain that is managed by their own systems(GMail).

Hi all! Thank you to the 34 respondents - that’s 56% of core contributors :raised_hands:t2:

Raw survey results are here, and they’re a really insightful read, so thanks everyone for sharing your thoughts.

We’ll be hosting a debrief hangout to chat about the results and bounce ideas for fixes - it’s tentatively scheduled for Thursday 5th September at 1pm CET. The invite will be in the Status calendar - more info to follow.

Cheers! c

2 Likes

Update: closing count is 37 respondents (61%) :tada:

We’ve read through all the responses and have summarised and categorised the feedback into a doc, with ten focus areas: 1) Hiring, 2) Leadership, 3) Vision, 4) Communication, 5) Training, 6) Values, 7) Technical & Development, 8) Finance, 9) Community & Contributors, 10) Quality of Life.

There’s a call today (2pm CET) to chat about the results and brainstorm ideas - join us! In advance of the call, feel free to edit/mark up/add comments to this doc to prioritise the topics you think are most important.

Cheers! c

Re:

Small group of very loud voices constantly heard, no one else taken seriously.

The above post is coming in a bit too late imo. It’s 3 hours before the call.

I know it was announced before, somewhat unofficially and originally for Thursday the 5th, but for those who missed or lost track of that announcement, this might be cutting it close a little - especially considering a minority of core contribs seem to frequent the forum. So here’s an admittedly crazy suggestion.

Add 5 DAI or equivalent in SNT or so per core contributor to a pool of funds, and make a roll call at the beginning of each call where people’s presence would be appreciated.

Have whoever is doing the roll call tick off present people in a list (very easy to build a UI for something like that), and once the call is over (for the sake of someone coming in late etc) submit to the pool with people’s public eth addresses (can be a single tx easily). All those who were present are now eligible to issue a withdraw function to the contract which gives them TOTAL_ETHER / PRESENT_MEMBERS ether. Alternatively, those who want to forsake their share can issue a forsake call which would add their stake to the next pool, or add it to some other initiative. All unsignaled eth is returned to the bank.

Just a radical thought on how to incentivize diversity in the calls and move away from those “few loud voices”.

Granted, this makes “greed” (if you can call it that for 5 DAI) the driving factor for participation, but I think this might lead to more engagement in general. If different people attend because of the 5 DAI initially, maybe they’ll be asked things or be encouraged to speak, leading in turn to further communication with them about their thoughts and ideas and making them more active participants, potentially bringing “interest” and “passion” in as incentivization after a few meetings have dispelled the “you actually don’t matter” or impostor syndrome feeling.

In turn, this might also help with:

People don’t feel like they’re making an impact. Don’t feel connected to the vision and how it all fits together

Feels like crucial decisions about the future of the organization are not being communicated transparently to everyone.

Hard to get hold of coworkers sometimes, acts as a blocker

The downside of this is that it makes each meeting cost 300 DAI or so (maximum), and another is that it’s “paying people to care”, which is no one’s interest. But if there’s a “vocal dozen” problem, I don’t know how else to solve this - maybe with some NFTs instead, but that would again not draw in the people who don’t much care about such things.

More added benefits of such an approach:

  • experimentation with minimal-viable-UI that has maximum friendliness to non-tech people
  • getting people who work at Status to actually use the blockchain and interact with both SNT and Ethereum at large through issuing transactions and learning how this works
  • increasing DAI/SNT utility
  • testbed for Status-first dapp (the UI can be optimized for Status, for example, or a perfect “native” testbed for internal experiments like relayed transactions even - consider having everyone sign their “I’m here” transaction during a call, and then relaying all of them or aggregating the signatures and sending that)

Lots of stuff to play with, just a thought. ¯\_(ツ)_/¯