Closed toomim closed 9 years ago
It would be too much backtracking work to port over the clicking single user part into master. I'd rather get the physics simulation working than backtrack. It has to happen anyway.
Michael Toomim wrote:
Can you help get the "clicking on a single user" part of histogram into master? That's the most important.
It shouldn't just expand the person's head in-place. That obscures everything nearby, and you can't explore his neighbors, which is a common task when browsing the histogram. It should pop up an expanded picture up above, like 100 pixels to the north, along with the user's name.
When you select a person, everybody else should turn grey. Don't just use opacity; that's not a strong indicator of selection unless you combine it with a greyscale/color difference.
With greyscale + opacity + big circle, we shouldn't need any other indicator of selection like yellow borders.
Let's get this into master and then we can finish the physics simulation and region selection codes later.
— Reply to this email directly or view it on GitHub https://github.com/tkriplean/ConsiderIt/issues/46.
It doesn't sound like a lot of work to me. Just copy the event handlers and highlighting code. Did you calculate how much work it would be or just guess?
On Jan 23, 2015, at 4:24 AM, Travis Kriplean notifications@github.com wrote:
It would be too much backtracking work to port over the clicking single user part into master. I'd rather get the physics simulation working than backtrack. It has to happen anyway.
Michael Toomim wrote:
Can you help get the "clicking on a single user" part of histogram into master? That's the most important.
It shouldn't just expand the person's head in-place. That obscures everything nearby, and you can't explore his neighbors, which is a common task when browsing the histogram. It should pop up an expanded picture up above, like 100 pixels to the north, along with the user's name.
When you select a person, everybody else should turn grey. Don't just use opacity; that's not a strong indicator of selection unless you combine it with a greyscale/color difference.
With greyscale + opacity + big circle, we shouldn't need any other indicator of selection like yellow borders.
Let's get this into master and then we can finish the physics simulation and region selection codes later.
— Reply to this email directly or view it on GitHub https://github.com/tkriplean/ConsiderIt/issues/46.
— Reply to this email directly or view it on GitHub.
We are live right now and could use the code today when users visit the site.
On Jan 23, 2015, at 4:24 AM, Travis Kriplean notifications@github.com wrote:
It would be too much backtracking work to port over the clicking single user part into master. I'd rather get the physics simulation working than backtrack. It has to happen anyway.
Michael Toomim wrote:
Can you help get the "clicking on a single user" part of histogram into master? That's the most important.
It shouldn't just expand the person's head in-place. That obscures everything nearby, and you can't explore his neighbors, which is a common task when browsing the histogram. It should pop up an expanded picture up above, like 100 pixels to the north, along with the user's name.
When you select a person, everybody else should turn grey. Don't just use opacity; that's not a strong indicator of selection unless you combine it with a greyscale/color difference.
With greyscale + opacity + big circle, we shouldn't need any other indicator of selection like yellow borders.
Let's get this into master and then we can finish the physics simulation and region selection codes later.
— Reply to this email directly or view it on GitHub https://github.com/tkriplean/ConsiderIt/issues/46.
— Reply to this email directly or view it on GitHub.
The highlighting code is not copyable, it is based on my new dynamic opinion selection approach.
Michael Toomim wrote:
We are live right now and could use the code today when users visit the site.
On Jan 23, 2015, at 4:24 AM, Travis Kriplean notifications@github.com wrote:
It would be too much backtracking work to port over the clicking single user part into master. I'd rather get the physics simulation working than backtrack. It has to happen anyway.
Michael Toomim wrote:
Can you help get the "clicking on a single user" part of histogram into master? That's the most important.
It shouldn't just expand the person's head in-place. That obscures everything nearby, and you can't explore his neighbors, which is a common task when browsing the histogram. It should pop up an expanded picture up above, like 100 pixels to the north, along with the user's name.
When you select a person, everybody else should turn grey. Don't just use opacity; that's not a strong indicator of selection unless you combine it with a greyscale/color difference.
With greyscale + opacity + big circle, we shouldn't need any other indicator of selection like yellow borders.
Let's get this into master and then we can finish the physics simulation and region selection codes later.
— Reply to this email directly or view it on GitHub https://github.com/tkriplean/ConsiderIt/issues/46.
— Reply to this email directly or view it on GitHub.
— Reply to this email directly or view it on GitHub https://github.com/tkriplean/ConsiderIt/issues/46#issuecomment-71207559.
I didn't believe you, so I went ahead and implemented it myself to prove you wrong, and it's been live on the site for most of today. It took me an hour and 5 minutes, including the time to read your code. I added functionality to display a mini-profile for the selected person as well.
I spent some additional time tonight making it better, beyond the 65 minutes.
How did your actions prove me wrong?
Why did you choose to post this here, instead of on the more active and up-to-date parallel email thread of ours, which contains more specific predictions on my part?
Why did you ignore my request to have a conversation to coordinate?
Instead of trying to collaborate, you take upon yourself the motivation "to prove you wrong". Your behavior reduces my interest in assisting with this election push. It makes it harder to keep the best interest of considerit in mind.
Add to the costs of your quest to prove me wrong:
Instead of this mess, we could have deployed a better dynamic histogram with a solid round of testing by now.
I think you're missing the point: this is an important feature for users of the election. We need it implemented. I asked you for help.
You said it's not worth implementing and refused. That's what I disagree with.
The rest of these things you're talking about are little details, much of which are irrelevant, some of them have truth, some of them have wrongness. Here are some wrongnesses:
[deleted to keep the conversation focused on the important stuff]
Ok, now let's look again at the big picture.
Proving you wrong is a good motivation because then you can reflect on why you said things that are wrong (or irrelevant) and didn't see the point I was making and asking for help on. I hope you can reflect on that now.
I told you earlier last week that the main priority with the histogram was getting a single user selected (e.g. because it's important to candidate debates), and that you could help with that. You didn't help, but kept working on the physics sim histogram. That's fine, because it's cool research, but then when I asked you for help on this now project, you seemed not to understand the main priority. So you brought up all these irrelevant topics. Maybe there's a pattern there to not hearing it twice.
Hey I didn't get your most recent "Histogram" email until now. This is the one where you explained the 2-3 hours, and that you think the new histogram is ready to go, and that you want to audio/video about it.
I think you're missing the point: this is an important feature for users of the election. We need it implemented. I asked you for help.
You said it's not worth implementing and refused. That's what I disagree with.
False. I never said it wasn't worth implementing single user selection and I didn't refuse to work on it. In fact, I've been working on the histogram for this reason for the past couple days. Single user selection is an important part of that work.
What I disagreed with was patching it in to master. I stated, and continue to believe, that we could have done that more easily and more quickly if we would collaborate on the histogram branch. I said it was too much work, and this continues to be true.
The rest of this conversation is about your underestimation of the costs involved in patching master.
It's not supposed to be a "straight copy" of the code. You're fixated on that concept for no good reason. In fact I asked you specifically to make changes in the original post.
This is a false claim. What you said was "Just copy the event handlers and highlighting code". You never mentioned anything specifically about making changes in the original post.
"Backtracking" is irrelevant. The goal is to make this feature work for our users.
False. Backtracking is material to a time estimate of the cost of reimplementing in master. We never differed in our goal to make this feature work for our users; we differed in our assessment of the relative costs of getting it implemented by patching master or by finishing the histogram branch.
"Merge conflicts" in design? That's a bullshit concept. It's wrong to think that. If you don't like my design then ignore it. If you like it then borrow from it. It doesn't take you any work to resolve, unlike a merge conflict in code.
This is false. There is an opportunity cost to creating a design that is tailored specifically to single user selections without accounting for group selections, instead of looking at a design that addresses both at once (which is why I wanted to synchronize). Again, I'm not saying this is a massive cost, I'm saying that it is a cost that should be recognized.
"Merge conflicts" in code: You're going to replace the whole histogram component, so just erase what I did. I'm already re-using your fetch('histogram').selected_opinions state variable, so the logic is the same. I did change the default for .selected_opinions to be [] instead of null, and initialize it now in Histogram component instead of fetch(). I felt that change was better, but could be wrong.
Again false. Your changes aren't localized to the histogram component. Meanwhile the histogram branch is 19 commits ahead and 28 commits behind master, meaning that someone will have to disentangle the changes across franklin.coffee from those that dealt specifically with the single user selection. Not a huge time cost (~10 min), but we're talking about an estimation difference of an hour or so.
You said it would take as long to finish the physics histogram as to get this feature into master. That's clearly wrong.
Why is this clearly wrong? There are two missing pieces from the physics histogram:
The histogram is not finished, and I doubt it will be finished this weekend
It could have been finished by now with a little cooperation from you.
I implemented "select an opinion" in 65 minutes, and if you were to do it (as I requested) it should be even faster because you wouldn't have had to read your code. The bulk of programming is reading code, not writing it. I think it would have taken me 30 if I had (a) already written your code, or (b) was writing my code from scratch.
Maybe I code more slowly than you. You're also forgetting the cost of testing that code, as evidenced by the bug you created. This is why I triple my internal estimates, especially for something that we're going to try to slip into production code with users at the ready.
You originally estimated ~3 hours when prompted. Now you're saying you estimated 2-3 hours, which is half wrong because you originally said 3. 3 hours is too long for selecting a single person, and too little for the histogram.
I said "3ish hours" at 2:51pm, then followed up with an email at 3:04pm to clarify my estimation. In that email I wrote:
I think that creating an alternate implementation of user selection in the old "user segments" approach will take 2-3 hours. I think that the new histogram UI I have currently in the repo is ready to go, aside from ~1 hour of cross browser testing. I don't claim the UI is perfect, but it can be improved upon easily. The only blocking piece is to calibrate the physics simulation for the large histogram. You've implied that that calibration shouldn't be difficult to do. But it is an unknown from my vantage point. Let me know if you want to coordinate on this via audio/video.
Now you're acting like an email 10 minutes later with greater depth is immaterial here. This is BS man.
Moreover, we still don't know the entire cost of this patching, which by now is clearly over 2 hours, and will probably approach three hours.
The goal is to get that feature implemented, not to argue. I asked for your help, and you started arguing with some things that were wrong and irrelevant instead of helping
BS
I could try to figure out what's actually going on in your mind, correct it, and then ask you again to help me implement the feature, or I could just prove your statements false and have the feature implemented.
You didn't prove my statements false. If anything, you've proved them right.
Proving you wrong is a good motivation because then you can reflect on why you said things that are wrong (or irrelevant) and didn't see the point I was making and asking for help on. I hope you can reflect on that now.
Wow.
I told you earlier last week that the main priority with the histogram was getting a single user selected (e.g. because it's important to candidate debates), and that you could help with that. You didn't help, but kept working on the physics sim histogram. That's fine, because it's cool research, but then when I asked you for help on this now project, you seemed not to understand the main priority. So you brought up all these irrelevant topics. Maybe there's a pattern there to not hearing it twice.
You're repeating yourself. I think it is you that needs to do some listening.
We need the new version of considerit to have this debate.
At the high level, your response is still missing my main point. And the details are going off the rails, even further from the main point. Now this discussion is a mess, and most of it is off-topic.
I did not just want this feature to be implemented, I wanted this feature implemented on friday. You can see that in the third message I sent in this thread.
When I just said "you refused", I meant that you refused to help me implement this feature quickly, like on friday. You decided to continue working on the whole entire histogram revision. I'm not saying that your decision was wrong. Where you were wrong was in telling me that the reason why is that it would take the same amount of time to finish the histogram as to implement that subfeature of the histogram. This is where I decided I could implement the feature myself, and prove you wrong, which hopefully explains to you what I meant by proving you wrong.
And let me be explicit that when I say you told me "that the reason why is that it would take the same amount of time to finish the histogram as to implement that subfeature of the histogram" that I was referring to this email:
Regarding clicking on a single user, I think that the effort of getting this branch to work is comparable to the amount of work necessary to backport that functionality. And since this branch is the future, I'd rather spend my time on it.
You've told me a couple times (along with kevin) to let you know how you could help with the bitcoin election. I asked you for your help, and a fight results, without any help.
Feels like you aren't giving me much ability to define the team's priorities with the bitcoin foundation. Yet, you didn't disagree with my priorities when I declared them to you... you just indirectly disagree with them via your inaction in helping me work towards them.
Let me repeat the priorities that I've been declaring to you since I visited portland.
You haven't disagreed, but said you wanted to try porting the physics code. Yet, now it seems that you implicitly disagree with my priorities, and your disagreement is leaking into these weird arguments when I asked for your help.
There is no need to make a choice between your (1) and (2). We could have had both. You're fixated on these necessarily being done separately.
When you suggested that single opinion selection is important for the bitcoin foundation, I estimated that it would be possible to complete that piece of work integrated with the dynamic histogram. And I was right. We could have had the dynamic histogram AND the single user selection by Friday if you would have cooperated. We could have moved to the future rather than patching the past.
I tried twice this week to synchronize on this very issue with you. I asked to demo this stuff to you one day, which you chose to substitute with comments on an old version of the code and going to bed at the time you said you could meet. I didn't insist on the meeting because you had clearly been up for 24+ hours. The second request was in that email you "didn't receive" -- which I would bet would more truthfully be stated as "chose not to read".
Meanwhile, I've been doing a ton of bug fixing, some that you've introduced, many that you've added to Github, to support the bitcoin launch. To focus on this one disagreement about process as representing a general trend of not helping you when you ask for help, and as an issue with your power in setting bitcoin foundation priorities, is absurd.
You chose to frame from the outset my attempts to synchronize on this issue as "weird arguments". Whatever happened to your high minded communicative value of "trying to find agreement" that you claimed to practice just a couple months ago?
p.s. "Comparable" != "Same". "Too much work" != "A lot of work". If you're going to be a word lawyer, at least be correct in your trifles.
Michael Toomim wrote:
Let me repeat the priorities that I've been declaring to you since I visited portland.
- Getting a single opinion selected is important right now, for bitcoin foundation
- Porting the physics code to each proposal is cool, but not critical, and will be easier and better once I am helping you with it.
You haven't disagreed, but said you wanted to try porting the physics code. Yet, now it seems that you implicitly disagree with my priorities, and your disagreement is leaking into these weird arguments when I asked for your help.
— Reply to this email directly or view it on GitHub https://github.com/tkriplean/ConsiderIt/issues/46#issuecomment-71369148.
So I'm hearing that you think I should have helped you to make the physics histogram work on proposal pages. Does that accurately reflect your main point?
It sounds like you are upset that I have not paid much attention to the histogram branch that you have been working on. Is that true?
So I'm hearing that you think I should have helped you to make the physics histogram work on proposal pages. Does that accurately reflect your main point?
It sounds like you are upset that I have not paid much attention to the histogram branch that you have been working on. Is that true?
No. My main point is that you should have tried to collaborate with me.
One possible outcome of synchronizing could have been you helping me make the physics histogram work. However, that is not the only possible outcome of synchronization, not even the most likely. Part of my estimation is based on your multiple assertions that getting the physics histogram to work would simply require tweaking the parameters. I stated this blindspot clearly. You could have convinced me that it was more work than I thought, despite your prior assertions (e.g. significantly more than the few hours we've now spent patching master). We would have together examined whether that implied we should port the code to master. The answer probably would have been an affirmative.
Instead of collaborating, you decided to embark on a misguided attempt to "prove you wrong". You inexplicably ignored my email with such a request. You ignored the opportunity to engage my perspective in this very thread, choosing to dismiss my perspective as "weird arguments". I still have no idea how difficult tweaking the physics parameters would be -- you've ignored answering that question, possibly because you're saving that for fire power in this argument.
I don't think you understand the concept of "asking for help". I never volunteered to implement without discussion your bitcoin foundation todos. You asked if I could help in one way, I suggested that we could achieve it better a slightly different way, then you blow up rather than engage. Sorry, that's not collaboration. That's not asking for help. That's an authoritarian upset that his grunt didn't carry out his dictate to the letter. I'm not interested.
No. My main point is that you should have tried to collaborate with me.
I'm trying to understand your main point, but I don't understand what you mean by this. Collaborate with you on what? My mind has many ambiguous interpretations of that. Can you clarify your main point?
On figuring out how to best make progress on the histogram functionality. Coordinating efforts.
This is obvious from my previous message, though I doubt you put much effort into trying to understand it.
Ok, let me check my listening of you. Your main point is that I should have tried to collaborate with you on figuring out how to best make progress on the histogram?
So it's not about making the actual progress, but specifically about figuring out how to make progress? That sounds like you wanted me to initiate a planning session with you. Is that what you wanted? Collaborative planning?
Did I want you to initiate a collaborative planning session? Yes, that would have been nice. I tried to initiate it earlier in the week. Then when you raised this particular issue (on Friday) via email (and via a parallel github issue), I again explained my perspective and offered to meet about it.
Is that my main point here though? No. I want you to collaborate with me. Allow me to rephrase this for you: I want you to approach our work together with a collaborative attitude. Does my main point being about attitude mean that it is only about "orientation" and/or "process", not about "progress"? No. It is about differing perspective about how to maximize our progress.
A collaborative attitude entails:
Some of the actions that may have emerged from a collaborative attitude:
With a collaborative attitude from which collaboration actions spring, I believe we could easily have had the dynamic histogram branch merged into master, well tested, and with a nice single user selection on friday, with no more effort on your part than what you put into proving me wrong about something. This would have maximized our progress. Now I have shift my attention to demographic information with the dynamic histogram branch floating around in limbo.
Instead of a collaborative attitude, I see you exhibit a competitive, authoritarian attitude:
You might claim, "hey what are we doing now? Aren't I the one asking questions now?" Yes you are, but from past experiences with you, I don't believe you're asking them from an open mind of seeking understanding. I think you're listening from a frame of psychotherapy, of trying to correct something wrong in me, as you stated earlier in this discussion: "I could try to figure out what's actually going on in your mind, correct it". I believe your frame is one of assuming that there is something wrong in my perspective, rather than being open to something wrong in yours, or in the communication between us. I can see you trying to dissect my "main point" into smaller and smaller pieces, such that you can pounce upon it and drown them individually. This is a pattern of yours, of turning a difference of perspective into a psychotherapy session on the other person. Maybe you're not even aware of this orientation of yours, maybe you are.
I find this non-collaborative attitude insufferable. I don't want it to be part of our culture. I won't live it. Personally or as a company.
More food for thought:
The principles of a collaborative attitude that I laid out above is the spirit of considerit: if we put our minds together we can find better ways forward, collectively.
You are advocating a shift in considerit to make it easy to dissect and dismiss people's arguments. I agree with the value of many of the mechanisms you've proposed, but I do not share in the spirit in which you put them forward. I see in your actions in this situation an embodiment of that spirit that I don't like.
We visited this difference of orientation a week or two ago from a different vantage point on chat (lightly edited to make more readable):
Michael: "I am thinking, another way to look at next considerit, is with the morality that our design would imply...we’ll be promoting a deeper, better form of thought on truth and whatnot. Reason."
Travis: "Try to express what you think is true, but be open to changing your mind. I think lots of morality boils down to that"
Michael: "And maybe we wanna promote reasoned thinking and discussions. These could be very powerful for mass peoples. Although many discussions today are not reasoned, maybe that’s by design — we’re promoting the ones that are, because we think they will win out in the end. This is similar to the philosophy of science that Sagan & Tyson promote. That philosophy is: • use reason • look at evidence • question authority We can be promoting the reason component, and evidence can be next. An extension of reason."
Travis: "I have some reservations about that framing that we can delve into. I like [those Sagan principles], but i think that with a sole focus on those, people become assholes that pick apart what others are saying and lose out on bigger meanings...kinda like the fernando flores effect"
Michael: "I’m thinking we could support a particular type of discussion, like “reasoned” discussion, and then the pledge could be “I acknowledge that this is a different type of forum. It’s not here to allow all thoughts — just reasoned thoughts. I promise to X, Y, and Z. My thoughts will be removed if they are not reasoned."
Ok, let me restate what I'm hearing of your experience. I'm hearing that you'd like to feel that we are collaborating, on the same team, trying to work together. You'd like to feel like I'm trying to make space for your ideas and interests, but right now you think I'm asking you questions only to argue, attack, and pounce upon your responses, and thus you don't trust that the things I say are coming from a good place. I hear you that you've found a number of interpretations of my actions, in which I am "authoritarian and competitive" — trying to compete, prove you wrong, and tell you to do things exactly as I say.
Does this capture the meat of what you are trying to tell me?
Also, I apologize for the delay in response. I've been out of it. I let me guard down and the darkness got me and I stopped being awake.
Yes, I think that captures it pretty well. And I realize that some of my interpretations may be off.
Ok, thank you. I think understanding each other is important for making progress in this conflict.
Can you now tell me what you hear of my main points? I suggest aiming for 1-3 points, at a sentence or two each.
Sure.
• You wanted to have single user selection in the histogram ready for bitcoin-election launch • You thought porting the single user selection code from the Histogram branch would be little work • You thought my preference for finishing the histogram branch demonstrated an unwillingness to help with the launch effort (and disrespect for your ability to lead the launch)
Ok, thanks.
Point 1 is right. Good. Thanks! This was my primary focus. Point 2 is not about porting, it's about implementing the feature. One way to do that is to port it. But the goal was to implement the feature for bitcoin-election launch, whether it comes from the histogram branch or not does not matter. Point 3 was not a big issue for me. This was just something I was talking about while trying to understand where the conflict was coming from.
And there's another point that I think is very relevant here (moreso than point 2 or 3):
What do you hear about my priorities in implementing the single-person selection vs. physics histogram on proposal pages?
The priority I heard: Single person selection: HIGH Physics histogram: low Dynamic selection: low
Ok. Does this help us understand the conflict?
I see:
And there is a conflict about mike and collaborating on the histogram branch.
It might help. I still don't understand your perspective.
Say I have a set of features, with priority: [A: 100, B: 1, C: 1]
Then I have two options in front of me: X has A, B, and C Y has A
X ~ Y in cost
I don't understand a preference for Y.
Ok, let me explain my perspective:
I don't care about finishing the histogram branch. Priority of histogram is 0.
My estimate for time to finish histogram branch has been at least 3x the time to get single-user selection to work. I can imagine in my mind how to implement single-user selection. I cannot imagine what it takes to finish the histogram branch, but when I look at it, I can see a number of problems.
Thanks for clarifying the zero priorities.
You do understand that I have priorities too? And that I'm much more motivated to do something if I can satisfy my priorities AND your priorities? You were yourself recently advocating "working on what you care about".
Here's an updated model:
Features + priority: Michael: [A: 100, B: 0, C: 0] Travis: [A: 70, B: 10, C: 20]
There are two options on the table: X has A, B, and C Y has A
And Travis suggests that we could do X pretty easily (comparable to Y) and that he's very motivated to do so.
If I were Mike, I'd want to hear more.
I still don't understand your 3x time estimate.
I can do that faster by adding it to master without finishing the histogram branch.
My estimate required very little of your time, though I was unsure because it involved the variable tweaking. It appears though from the discussion of #57 that the amount of time would have been even smaller than I expected. Like maybe 10 minutes explaining y_force_mult in a deeper way than "tweak y_force_mult". Certainly less time than you spent hacking in single user selection.
I cannot imagine what it takes to finish the histogram branch, but when I look at it, I can see a lot of problems
On Friday, we could have pushed what I had in the histogram branch already, after an hour or so of testing. I don't see blocking problems in that branch. The UI could be improved, but I think it is quite good already; superior to the manual selection. I don't understand what you see as "a lot of problems". If the problems are the minor UI suggestions you have emailed about, then we aren't in agreement about their severity. Or their difficulty in overcoming. Or the amount of time that you need to spend on them, vs just giving some quick feedback.
Travis, it sounds like you are moving on to new issues:
Have we resolved the issue of you wanting me to be more collaborative? I want to complete our issues before we move on to new ones. This thread of conversation is much too messy already. I do not like how many different things you say at once. There is no focus.
Or, rather, have we understood the conflict? How would you describe the conflict?
Michael, how can I say that we understand the conflict if I still don't understand your perspective?
If I understood that, I might better understand the conflict.
Have we understood the issue of you wanting me to be more collaborative?
I thought we already agreed on that. It seems like we haven't yet come to an understanding on your perspective.
This is how you can understand the conflict without understanding these two points:
A conflict occurs when two people want incompatible things. Right?
You can understand what my priorities are without knowing how I calculate them. Right? If you understand my priorities, then what I want becomes clear. Right? Then you can understand the conflict, by comparing these things with what you want, and looking for incompatibilities.
When I say "understand the conflict" I mean "understand what the conflict is." Can you describe what you think the conflict is? It suggest that it can be done in 1-5 sentences.
Let's be clear. There are two conflicts here.
I am interested in understanding your model of the situation, not just the outputs of the model, which is why I have been asking questions beyond the superficial priorities of the situation. I believe that the common root of these conflicts is in a difference in collaborative attitude.
But it sounds like you want to establish, firmly, what the initial conflict of interests/priorities was, and I respect that. You've asked me to define the conflict in terms of a difference in what we both wanted.
This is my current model of what we both wanted initially regarding implementing this feature in master:
As far as I can tell, (4) is something like "Mike was stressed out and wanted a solution that took little energy to contemplate" or "Mike wanted to feel control over of how things are done" or "Mike didn't want to coordinate with Travis" or some combination therein.
Look, I just spent 11 posts with you to create common ground on your main point—the issue you have with me being uncollaborative—so that I can help you resolve it. Can we resolve this before moving on, please? I want to make progress on what we've agreed is most important.
I am NOT interested in what the initial conflict of interests/priorities was. I am interested in resolving your main point.
How would you describe the conflict between your main point and my main point? Why don't you agree with the description of the conflict that I proposed in https://github.com/tkriplean/ConsiderIt/issues/46#issuecomment-71965448?
Fine. I'll modify your points so that it spans the main conflict across this entire episode.
4 & 5 are the most important conflicts to me; 3 could easily have been avoided with 4 & 5. (1) is a generalization of my interests in 3-5.
To simplify even more:
(I presume you think this last simplified version is better than the prior 5-point one, so I'm focusing on it.)
The last point you listed is not true. I have no aversion to resolving differences collaboratively.
Can you adjust your view to this new information?
I cannot. I see too much evidence to the contrary. If you'd like me to rehash this evidence so that we can look at it together, I can do so.
Can you help get the "clicking on a single user" part of histogram into master? That's the most important.
It shouldn't just expand the person's head in-place. That obscures everything nearby, and you can't explore his neighbors, which is a common task when browsing the histogram. It should pop up an expanded picture up above, like 100 pixels to the north, along with the user's name.
When you select a person, everybody else should turn grey. Don't just use opacity; that's not a strong indicator of selection unless you combine it with a greyscale/color difference.
With greyscale + opacity + big circle, we shouldn't need any other indicator of selection like yellow borders.
Let's get this into master and then we can finish the physics simulation and region selection codes later.