Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/more work 20230214 #11

Merged
merged 4 commits into from
Mar 2, 2023
Merged

Conversation

windoverwater
Copy link
Collaborator

Previous edits from a few days ago

stratofax
stratofax previously approved these changes Mar 1, 2023
Copy link
Contributor

@stratofax stratofax left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, I think adding numbers and letters to Markdown headers is not needed and adds more maintenance burden to the doc. If you want a version of the doc with a "classic outline" style, you could render it as HTML and attach a CSS that autonumbers headers and subheads.

Also, it's "Retrospect," not "retro spec" -- which are, I believe, old-timey glasses ("retro specs")

Minor edits, though, nothing to prevent this from dropping onto main.

@windoverwater
Copy link
Collaborator Author

windoverwater commented Mar 1, 2023

Note - the repo is currently configured to require a new approval with any additional commit - which there is one now. Is that ok? Whatever you want (as this is more your repo than mine).

FWIIW, I like that setting in my repo but believe it is one of the many owner's choice settings. But then I also like have the explicit numbers in markdown header lines to help myself and perhaps (?) other ADD people remember where they are.

Copy link
Contributor

@stratofax stratofax left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if you're not sure about a design decision, we should discuss it and resolve it, instead of questioning it in the doc. This is probably as good a forum as any. Please elaborate on why you think multiple votes from one phone is not good, in retrospect.


1. We decided to allow participants in the demo to vote as many times as they would like so to gain experience with RCV and VTP and to allow multiple people to use one phone. This might be a bad decision - in retro spec it seems like it. It may be that we want to minimize the number of things that can confuse the voter (even though in real life they will not be voting by phone). Regardless, to prevent multiple votes the solution would need to work across multiple browsers.
1. We decided to allow participants in the demo to vote as many times as they would like so to gain experience with RCV and VTP and to allow multiple people to use one phone. This might be a bad decision - in retrospec it seems like it. It may be that we want to minimize the number of things that can confuse the voter (even though in real life they will not be voting by phone). Regardless, to prevent multiple votes the solution would need to work across multiple browsers.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So close! "Retrospect" not "retrospec"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, you could just delete this whole sentence. It's odd to speculate on what a bad idea a design decision is in this document. Maybe move this to Discussions, or discuss here, if you're not sure about this part of the plan?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am fine deleting the sentence. The reason I was thinking it was a bad idea (to be able to vote twice) is that I can see people associating being able to vote multiple times as something inherent with VTP. Yes we would say that it is not the case, be we are going to be saying a lot of things. At some point too many things said will be blurred, and the blurring point is different for different folks. But the tradeoff in this case is ok IMHO - let people vote multiple times.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I am thinking that changing and discussing the doc is ok as that is what the PR process is for. However, I am fine if you want to bring the doc back into a discussion topic. I was just trying it (the process) out as a checked in doc. You can pick.

Copy link
Contributor

@stratofax stratofax left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is good to go!

Also, regarding the many shortcomings of this demo as a "real-world" voting system, like being able to vote multiple times from one device, or allowing dead people to vote, as long as they have a good WiFi connection: we just need to point out that this demo is not secure, and is not intended to be secure, but that was a deliberate decision to make the demo more accessible and encourage people to try it out -- literally one of the main principles of open source software!

Also, I hear the WiFi in heaven is excellent, but in Hell it's provided by AT&T so it's hard to get a good connection...

@windoverwater windoverwater merged commit 840033f into main Mar 2, 2023
@windoverwater windoverwater deleted the feature/more-work-20230214 branch March 2, 2023 20:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants