A Note to Players from Eyewire HQ


HQ has been busy fixing bugs, building features, and preparing for Neo. Along the way, we strive to work with players and solicit feedback as much as possible. It has come to our attention that there are concerns in the community that your input is not heard or acted upon. Please understand this is exactly opposite of what we are trying to do, and we apologize if you feel you are not listened to.

Please remember that we are a small team. Chris, Marissa, Celia, Devon, Daniela, and Amy. This is all of us at Boston HQ. We are a working hard to maintain Eyewire and Mystic as well as prepare for Neo. We write blogs, scientific papers, and grants to continually fund this endeavor. Of course the GMs also check all the cells and prepare new ones so you (hopefully) never run out of cubes. We produce neuroscience images and visualizations to try and share the scientific journey with you. Chris builds new features, works on neural data access, and spends a lot of time fixing bugs and trying to speed up Eyewire. We are earnestly working our hardest to make Eyewire the best place it can be. Of course, none of it would be possible without you. We appreciate your thoughts and opinions and want to understand if there is anything we are doing that makes it seem otherwise.

We’ve come up with some ways going forward to improve the ease of communication between the players and HQ and make sure that we are always getting player input along the way.

Beta Testing Days

  1. In order to allow more players to beta test big features before they launch, we will start giving advance notice to the community when we are going to beta test a major new feature with 24 hours notice before beta testing begins.

  2. We will then give a window of 24 hours to beta test and solicit feedback before a feature is implemented.

  3. We will have 1-2 set time blocks for live testing during that 24 hours when Admins will be online in chat in the beta testing site to gather feedback and converse with players about their feedback. If players cannot be online during this time period we will have a forum post to gather feedback before we release the feature. We welcome both positive feedback and constructive criticism to any new features. There may be times when some players like new features while others have different opinions. We will do our best to accommodate the majority of players. Please make sure to leave your positive as well as negative feedback so we get a good picture of what is liked and what is disliked.

Bugs Reports and Feature Requests from Players

We are setting up a sheet for feature suggestions and bug alerts. Devs and admins will check this sheet regularly and present a weekly summary during our team meetings. We will not always be able to fix every bug or implement every suggestion, but we will make sure that community desires and concerns are heard and addressed.

Immediate priorities.

We are currently working on the following items:

  • Fixing seg grenades
  • Giving Freeze to players
  • Fixing location of Reap in Review Mode
  • Finding and fixing slow queries that are impacting the whole site

Thanks for being a wonderful community and for helping us be innovators for the way scientific research is done, and will be done in the future. If you have concerns or feel that your voice is not being heard, please comment so we can address them and return to happy homeostasis.

Now and forever for science,
Eyewire HQ


Really good post. I’m happy, that you at HQ are not only actively developing and maintainting the environment, but also hear our voices. The bug sheet sounds great.
Just one thing: please, inform us about any changes/new features that you are planning to implement before they are actually added to the code base. This way both the players might be less surprised (positively or negatively) and dev(s) might have less work, if majority of the players won’t want a particular feature/change.



Agreed wholeheartedly. :slight_smile:


Hi Krzysztof, thanks for the feedback. This actually did come up at HQ’s meeting yesterday, because we agree there have been challenges with transparency. Usually we do try to inform people by virtue of having them beta test, but because the window for that used to be so brief/random/unannounced, maybe word didn’t always get out. And sometimes there have been outright surprises. Yesterday we decided to adopt a clearer policy of “no surprises” regarding permanent changes to user experience. That means that temporary things like competition themes may still be cloaked by Grim’s robes, but new UI/UX, game mechanics, etc., will be open for us to discuss before beta testing even starts. Sometimes we’ve been transparent in the past, but we aim to be more consistent about that going forward. I hope this answer helps address your concern!


Thanks @devonjones for the answer. Yeah, that partially addresses my concern, but I would like, if you inform us even earlier than before beta testing. The best moment would be between making decision to implement a feature and starting the implementation, because, if there’s only one dev, every line of code matters :smiley:

1 Like

I’m excited to see the new sheet! I’ll definitely be sure to add anything I can think of that’s likely to be outside the scope of our own ‘self-support’ efforts!

Thank you all again for reaching out and giving us an ability to be more communicative!

1 Like

Hm. I suspect the main obstacle to that type of informational process might be that there’s two kinds of decision we can make to implement a feature:

a) We decide “this is something we definitely plan to do and Chris is going to start working on it in the next day or two.”
vs. b) We decide “this is something we definitely plan to do but Chris needs to get some other stuff out of the way first.”

In scenario b) we might wind up eventually deciding to not actually build that thing anymore because the need for it changes or disappears in the interim. So maybe if we announced every new feature we’ve chosen to do as soon as we decide, we might give people false impressions of what to expect imminently/ever. But I do also imagine we could at least be fairly upfront about scenario a), especially if someone asks us in chat for an update on the “thing of the day” so to speak. For scenario b), we might need to talk again at HQ about how to handle such situations.

1 Like

More communication is great, so you are most welcome!

1 Like

Yeah, I totally understand that. I do program myself and I know, how things can change during the process. I was rather thinking about changes/features, that affect most/all of the players, like: “We’re gonna change the Scythe Vision heatmap. How would you see it in the future?”, or "“We’re gonna change the inspect bottom bar. The plan is to remove the jump to child/parent button and make the jumping by double-click. Would you like that, or the current way is better?”, or “We are going to change this and that and it’s a must for the future. What would be the best way for you to do that?”. <- Something like that.


So to me, your phrasing here reads less like you’d prefer to be alerted as soon as we decide to develop something, and more like you’d prefer to be alerted as soon as we decide that an existing feature needs to be altered, regardless of how major or minor those alterations may become, and regardless of whether we already have ideas in mind for what changes to make. Personally I would find this way of communicating to be more realistic because at HQ we often say, “We should change x because the existing y scheme has z problem,” long before anyone has the time to sit down and hammer out a spec sheet for x 2.0. In those instances I’m sure we could ping players more about whether they agree that z is real, what they still like about y, and whether they have any suggestions for x 2.0, and eventually we could incorporate those thoughts into whatever meeting (days, weeks, or months later) where we actually make the spec sheet.


yes, i think that getting more of player feedback/UX prior to changing something that exists and we have been using for god knows how long will create a lot less grief after than otherwise. imho. I don’t think anyone “expects”/“demands” all of the feedback to be incorporated but some is better than none, and prior rather than post i think ensures less grief lol :slight_smile:


In short:
I would like, that the players could decide as early as possible about features/changes, in which they could have someting to say. Just to save some planning/developing time, e.g.:

  1. We are going to change this and add that, because we can - would you like it to be changed/added and how it should look like?
  2. We are going to change this and add that, because it’s a thing, that will be needed in the future or is needed to fix something else - how it should look like?
  3. We are going to change this and add that, because it’s a thing, that will be needed in the future or is needed to fix something else and it have to look exactly like this. We are just informing you to be ready for it.

Of course not everything should be passed to us, just changes, that are visible, like some larger changes in UI or functionality.


Okay. I can’t singlehandedly answer this question much further right now, but thanks for clarifying. At the next HQ meeting where it would be convenient to discuss this process, I will ask everyone else what protocol we can reasonably adopt to alert and solicit feedback from players about planned UI/UX/gameplay changes once we have either a) made a spec sheet for changes we believe are best for the game, or b) decided that change is needed and player input can/should happen before making the spec sheet.


Ok, thanks :slight_smile:

1 Like

yeah, thanks that’d be great :slight_smile:


i like that, thanks! :slight_smile:

1 Like

Was wondering if y’all’ve ever considered having a few players designated as “player liaisons?” Players who can act as a go between HQ and the rest of the playership. So if HQ needs something from the players, the liaisons can help work to make it happen and disseminate information better (particularly as HQ is not available 24/7) And they can relay messages from the players to HQ. (Or as the recent stuff has brought to light, the liaisons could help to gauge the “mood” of the playership as well and ask HQ to intercede before it gets nasty)

This isn’t really a feature request, as nothing would really need to be done in-game to make it happen, just something to think about.




(ps that was a very intensified +1 lol)

1 Like

Sounds good so far, yes? I do appreciate that you are making this effort to communicate with us about the UI (and other) changes. In my case, I am not a super fast player, and I like to think that given enough time I can adjust to most changes in the UI without too much trouble. (There are other players who don’t have that luxury.)

What I personally do have trouble with is comments like the ones you made in chat (noted below) demonstrating a dismissive attitude towards me, and comments I have seen you make in chat that demonstrate it towards others, including your gm’s. They - the game masters- have been quite professional and have not discussed this with me at all – I base this comment only on my personal observations and they may have entirely different perspectives on this – I have no way to tell.

"(scouts) sounds like you feel we are not being fair to you.
(scouts) rinda please stop
(scouts) if we can train someone with dif. trace colours to “see” confidence levels and/or dupe segs whih to me are gold and to someone else are green, why wont we be able to do
(scouts) teh same with ov?
(scouts) seriously, we will never be ohn good terms ever since you sent that horrible email to the whole team about me
(scouts) just now is NOT a good time

I don’t think this is up to the standards of communication and respect you expect from your gms. If you expect honest and respectful communication from them, should you not also do the same?
If you are truly convinced that we can never be on good terms again how can we communicate? And if we are never to honestly communicate how can we resolve this? I am willing to work on it.

Since you did bring up that email (and unavoidably the interactions associated with it), I could look for a copy of it. In any case there are people here who will still remember that incident, including @hsseung . I’d be happy to share that “horrible” email publicly - as I recall the part you didn’t like was me quoting what you had said to me.

Another note on communication, I am wondering now if you consider our communications with support to be public or private? If you hope for open and honest communication from us, you might want to consider keeping those confidential.

Please consider that as the current head of Eyewire, you in a way “own” both our accomplishments and the problems we are facing. Taking responsibility for the problems is one of the hardest parts, and I wish you well as you continue to work on resolving them. We players do care and are willing to give you the best we have to offer, even when it’s difficult. Please give us credit for that.


And another thing, do you honestly think that we as players haven’t picked up that you guys are overworked and overstressed and completely snowed under? There’s a lot of us who are straight up worried about you guys.

So my request is for you guys to let us in. You have a very talented group of players who all we want to do is help you guys out however we can. Let the hacker players help Chris with the development stuff. Let the artists and designers in your playership help with some of the art. Let your bloggers and YouTubers help drum up interest in the game. Let your players use their talents to help you guys. Just think about the tasks you do from day to day for the next week or two and think “is this something a player could help me out with?”

And yes I understand that this takes away the air of mystery and the air of surprise. And I also understand that it’s an unconventional way to run a citizen science game. But when has eyewire ever been conventional? :wink: