Ok, this is my answer to the current dispute.
I have huge problems with the new function, couldn’t sleep last night, and I am still in a churning constitution. Perhaps too early to communicate, but I must get rid of my thoughts. Eyewire got big part of my life as you know, and now there is a big question how I can go on and still keep fun.
The reason we needed to release this in the long term was that we can only give folks an accurate picture of their SCing by making sure a player’s SC tally only includes votes that are correct. “Scythe Complete” means and has always meant for a Scythe to say, “This cube’s consensus is accurate and does not need changes.”
Comment: We only complete when we think a cube is correct. In the new system you punish a scythe who perhaps made a small error by just missing a dust-piece. As you say how to handle dust below, you say dust is not important, so why punish.
Some longstanding bugs and now-resolved issues (like a lack of Scythe Freeze) have led to Scythe Complete being used for secondary purposes or inconsistent branch review techniques; we have hoped to finally adjust our mechanics to make SC votes only persist for their intended use case.
What’s so wrong on the secondary purposes? We obviously loose these now?
But again, we sincerely apologize that we were unable to discuss and test this before the release rather than afterward. We know that on the surface this is a small change, but deeper down it could alter how some of you may have approached SCing for years.
Yes, we did well for years, and now not good anymore.
In an effort to reach better understanding all around, we hav
e identified what seem to be all of your specific concerns with this change, and below are point for point answers from all of us at HQ. Once we have an understanding, the GMs will make sure the Scouts & Scythes Manual is up to date in its phrasing. (And apologies that this is long! But we wanted to make sure we didn’t skip over much.)
Concern #1: In Forts, can people still SC cubes that don’t need to be reapgrown? What happens if someone wants to reapgrow every cube on a branch?
“Wants to reapgrow every cube”? I reapgrow every cube, thought this was necessary and I would do also in the future. Why not reap a cube you are in which is good, you needed time to look into, and get rewarded with 30 points. Reaping and getting the points doesn’t harm anybody. It also shows the scythe-completing scythes after you, that cube has been looked at.
Yes, in Forts you can still SC a cube without reapgrowing it, as long as the AI really did trace correctly. As always, though, please first reapgrow your branch without SCing. Then come back and check it or have someone else check it.
If you are checking someone else’s branch and it’s mostly reapgrown but not SC’d, you should reap problems during the course of SCing it yourself. If you’re checking a branch that’s both reapgrown and SC’d, please don’t reap their SC’d cubes unless they have problems.
?The latter sentence: Nobody reaps a cube with no problems, what you want to say?
Concern #2: What about dust reaping? Couldn’t someone do that maliciously?
If you discover missing dust or merger dust in the course of inspecting a cube, it is currently okay to reap accordingly. Fundamentally the consensus was not correct, and you are within your rights to correct it. At the same time, please do not spend time just reaping dust along the majority or entirety of a branch
; and if you believe someone might be doing this, please let us know.
You say that my way to sc (as explained above) is bad or what? Feel accused
If necessary, we may build a way to not auto-remove SC votes for Scythe reaps where the changed segments are under a certain voxel limit, or something similar.
Might be a solution to my problem
Concern #3: Could/should Scythes get a “nuke” button alongside or instead of the new change?
The “uncomplete” button was always supposed to permanently remove the name(s) of people who had incorrectly SC’d before. It’s unfortunate that this wasn’t working, and thus that this bug may have lasted long enough to seem like a feature. But Scythe Complete was always supposed to work such that the only people who wind up having their SCs “counted” are the ones who correctly state that the cube is complete. Attaching automatic “uncomplete” to all reaping now bypasses that bug; and regardless of when we fix that bug, we suspect a separate “nuke” button outside of admins would prove redundant.
Never missed a nuke button, I am principally against nuking things somebody has done. One loses information and nuking creates uncertainties for us scythes about our past doings
Concern #4: How does this affect Scouts’ Log procedure?
In the future, we will be revising whether/when 2 votes are needed for locking a cube in the first place. Ideally we’d like to make it so that 1 vote locks, and 2 votes are simply required for admins to know the branch is really done.
Sounds ok, but do as soon as possible!
Until that change can be figured out: we may have requested this before, but going forward, Last Scythe Wins means it is not necessary to log cubes as “Scythe Complete” unless:
a) you want to lock the cube without reaping it,
or b) you reaped it after it already had at least 1 vote and now you need a second vote again.
Most reasons to intentionally lock the cube with 2 votes should be resolved simply by reaping away the problem. If you have reaped a cube and needs no further attention, please just create a log entry to explain what you did but set the status to “Good.”
Ok, disadvantage is just: By completing a cell, till now, one could assume that the blue reaped cubes were also double-completed and needed no further look at, so in the future one would have to inspect also these cubes.
Concern #5: Won’t duplicate effort wind up being spent?
We aren’t too worried about this. Here’s why: the general procedure for branch review is that one Scythe checks a branch from the parents to the children. They SC and reap as they go. A second Scythe then checks the branch, SCing as they go and reaping any additional issues they find. If they follow the logging procedure described above, then sometimes a third Scythe will need to come in and add their vote for a few cubes, but that’s it. Basically: reap first, then Scythe Complete. When a Scythe adds their SC vote, they’re saying the cube is perfectly traced; therefore it should not need to be reaped afterward unless there is an error.
Perhaps do not understand all what you say, but in my experience it is quite a lot of double work which could be spent better otherwise (and that’s also a cause I have big problems with the new application – I do not like to do things for nothing)
Concern #6: What about test extensions?
We would like to discourage Scythes from SCing test extensions until they are certain the new branch really belongs. Please log the starter cube as “Watch / Test Extension” and give it some time to grow before SCing. At the moment, if a test extension is SC’d and it turns out that this was incorrect because the extension was bad, these votes are already subtracted from players’ SC totals once the extensions are reaped out and stashed.
Concern #7: SCing takes work, so how is it fair to remove acknowledgment/points for that?
Making sure that we have accurate Scythe Completing is critical to the scientific process. It is the final verification of the cell, no different than making sure we have accurate consensus in each cube. Our points system for normal gameplay also “punishes” players for lower accuracy by giving them less points. This is a core part of Eyewire.
It’s true that by completely erasing old SCs that were wrong, we are not giving people recognition for pure effort. We do give that sort of recognition during normal gameplay with the time/volume component of cube scoring.
You cannot mix playing and scything. Me personally do more points by playing, and still I do scything because it’s something different and interesting and helping finishing the cells. And honoration for it of course is also important
One compromise could be that all of your SCs that remained at the end count toward a certain number of bonus points, while all of your SCs that were incorrect count toward a lesser number of bonus points.
Why not, ok, problem is still that at the moment one does not know what is the real status, perhaps @Galarun ‘s idea about info over notifications could help.
Concern #8: Some of us prefer to SC and then reap; now we have to reverse it.
Fundamentally it would not be correct to SC the cube before its problems are fixed. However, we know that many of you have wanted a way to SC inside the cube, so we may create an interface change where you can either just reap the cube or reap & SC together.
Would be good to integrate!
Hopefully that covers everything that’s been asked about. We would like to conclude, though, by noting that while there are concerns about Scythes improperly reaping to rob others of bonuses, the SC system so far has not been completely fair either. There have been lots of opportunities to SC for stats boosts alone, and not many ways to disincentivize that behavior. Although we deeply regret the mistaken deployment of this change to SCing, we also look forward to dialogue with all of you about how to make SC mechanics better in general.
I am very unhappy about your saying … improperly … rob…. Never felt a fellow-scythe worked against me. I’m sure, we all do our best, some do more generous, others more accurate, but together we came to the correct result in a rather good time. We all do for science, ok, also for points, but not against eachother!