Help testing NuFeeder voting manager

cryptog 2015-12-31 07:15:57 UTC #4

Nice. I ll give it definitively a try

willy 2016-01-01 04:10:02 UTC #5

So if I use this tool, my voting configuration will be publicly available in any case?

CoinGame 2016-01-01 15:19:18 UTC #6

Yeah. For now the only way to obscure yourself personally would be to create a dummy github account and use that.

Mark 2016-01-01 19:12:31 UTC #7

Is it possible to use private Bitbucket repo?

CoinGame 2016-01-01 19:45:05 UTC #8

I don’t think so. The way this works right now is by using what is called Github Page. It takes the source code of the repository and hosts it like a regular web server. So github is both hosting the application that creates a GUI to manage the datafeed, and it’s the datafeed itself. I don’t think bitbucket offers a service like that. I’m not sure how you would give the Nu wallet access to the voting data file if the repository was private

CoinGame 2016-01-01 20:01:49 UTC #9

I’ve updated the usage instructions. You need to do a push to the repo in order for the github page to be generated after you fork the repo. So I’ve added a useless delete.me file to the root of the repo. When you delete this file after forking it will trigger the github page generation.

cryptog 2016-01-01 23:11:24 UTC #10

It works well! Tks for creating such a tool.

park rates: how is “null” is interpreted by qt?
any plan to add a signature generator?
any plan to add “signature url” and “signature address” fields?

CoinGame 2016-01-02 01:08:18 UTC #11

For park rates do you mean null as in not adding the park rate at all? I believe it considers that a vote for 0.

I have not thought about the signature part yet, but if it can be added I will ad it.

EDIT: to add on I think there’s a number of improvements that need to be made before the signature. The UI needs to be cleaned up a bit. I want to allow the user to select between the same durations that are in the client (like 3 month, 6 month, etc) instead of having to enter in block numbers. Some back end stuff as well. Right now it requires having the vote file pre-structured with the correct voting structure, but it should have that memorized internally. Lots of little things. Glad the current state is working for you for now though.

Cybnate 2016-01-02 03:23:06 UTC #12

It works well, good work!
What I like to see is a way to nicely display the current voting configuration with the links to the forums for anyone.
That way the content of the actual datafeed is easily accessible.

Edit: and same here the signatures is a must have for datafeed providers I believe

CoinGame 2016-01-02 03:50:08 UTC #13

Ok so based on the few responses i’m starting to see a bit of a design change that I wasn’t thinking of originally.

I can make the main page like a “status” page which displays the current configuration for that users repo in a nice organized way. That way people can see the current voting without having to log in. I think that should be really easy and I can make it part of the next UI updates.

The part about linking back to the actual proposals is a bit more difficult . There’s a few ways to do it that I can think of off the top of my head. Have NuFeeder fetch from a curated list that has links associated to motions and custodial addresses. Then there’s trying to parse the data from somewhere. Third option is just adding a field next to custodial grants and motion in NuFeeder that allows to add an optional link and an optional comment.

Wherever the information gets pulled from I can then turn motion hashes and grant addresses into clickable links on the users NuFeeder status page.

The first one requires a person or some people to manage this repository of the associations between links and hashes/addresses. The second option I think is outright impossible because there’s not single place or uniform structure to pull this information from reliably. The third option is probably a lot easier. I would just create a separate file somewhere in the repository that stores the association between the voting data and the meta data. This would be stored separate from the vote file.

Am I missing some other easier way of implementing it? I would love for the link associations to happen automatically by pulling from some curated API like in the first option, as it would take the extra effort from users managing their feed in the third option. I’m not willing to say that I myself would commit to managing and updating such a listing. Maybe the third option is the most feasible?

Cybnate 2016-01-02 04:08:48 UTC #14

I would like to see that, hope I’m not alone in that.

I’m already doing the associations anyway in my datafeed thread for the items I’m adding to my feed. Instead of making the links in there I can make the links on Github in a designated field. One step further would be to have this accessible for any feed, but that would require a primary host and someone making sure any proposal is added. Happy to host it. The block explorer could also benefit from that.

The other option is pulling them from the Voting thread. We could structurise that a bit and then you could potentially scrape it.

mhps 2016-01-02 06:06:52 UTC #15

Don’t know if this is easy to do but how about this -
somehow allow the proposal writer to generated a link to put in the proposal, such that when proposal reader clicks on it, a new page will open showing the reader’s NuFeeder’s page, with this proposal’s hash/amount and name added, and ready to be voted with one click. This basically gives an incentive for the writer to add the voting info (to the link) himherself because it brings convenience to the voter to vote yes.

cryptog 2016-01-02 08:00:56 UTC #16

Ok cool.

CoinGame 2016-01-02 08:06:47 UTC #17

that’s possible I think. I can look into it.

I’ve made some updates to the repo. I fixed how it handles some things internally. There’s now some color coded alert messages that I will use to notify users of events. the “development” button works now. It will basically point changes to a branch on the repo called development. If you want to test things or make changes to the code without it impacting the actual gh-pages branch with your votes just click the development button. make sure you create a “development” branch first. Fixed some small layout bugs as well.

for those that already forked it’s fairly simple to update with my repo. go to your repo page:

http://github.com/<your-username>/NuFeeder

then add /compare/gh-pages...CoinGame:gh-pages to the end of the url:

http://github.com/<your-username>/NuFeeder/compare/gh-pages...CoinGame:gh-pages

Click the “create pull request” button (give it a title if you need to) then just merge the pull request into your repo. That will update your gh-pages branch with my latest gh-pages branch. The voting data shouldn’t be affected, but you can see if it is in the pull request.

CoinGame 2016-01-02 08:09:29 UTC #18

Sorry I think I misunderstood your question, but I went to your repo and I see the issue. That’s a bug. If you accidentally left votes without data being entered it should discard those instead of creating entries with null values. For now just delete the empty entries from the GUI and save the results again. I’ll fix it in the future.

cryptog 2016-01-03 08:26:39 UTC #19

Cannot merge. It says “This branch has conflicts that must be resolved
Only those with write access to this repository can merge pull requests.”

Also, [quote=“CoinGame, post:18, topic:3253”]
For now just delete the empty entries from the GUI
[/quote]

deleting (leaving a blankvalue for the fields I do not want to vote anything for) will put a null value…

CoinGame 2016-01-03 16:04:35 UTC #20

Sorry I made a lot of changes yesterday that could have caused the issue. I think the structure needs to be organized better to handle people updating through github. I’m trying to make the process as simple as possible so that non-technical users don’t need to deal with git, but it’s a bit of a learning process in how to set things up correctly myself. For now the easier way might just be to copy the contents of your votes.json file, delete the entire repo, then fork it again and copy the data back into votes.json. Note that votes.json that moved to the _data folder.

I made some big changes yesterday. The biggest being that the application was restructured to use jekyll templating, which is what github uses to generate the pages. It makes things a bit more flexible. The second big change is that now the main page of the application is a “status” page which will show the current settings for the votes. You can click “edit” at the top to see the familiar login screen and vote editing functions.

The status page is still very ugly. I need to redo it, but it was good enough for my testing. I’m going to try and figure out a consistent way for uses to update their repo, or figure out what I’m doing that’s causing the merge errors. It could take some time though.

regarding the null issue… why are you leaving blank form items in the first place? Just delete those items. Items that don’t exist count as no votes with their default values set to 0. For instance delete all of the park rate inputs and those votes will be considered as setting park rates to 0. I will have the application automatically remove empty inputs when I get a chance.

Cybnate 2016-01-03 23:27:05 UTC #21

Figured that and just created a new fork. Nice work so far.

cryptog 2016-04-22 04:06:07 UTC #22

Any improvement?
I d like to use NuFeeder instead of having to use the same laptop each time…

CoinGame 2016-04-22 17:27:56 UTC #23

I haven’t had time to work on this right now. I think it works fairly well though for tx fees, motions, and custodian votes. The problem is park rates needs to be more user friendly. I’m not sure when i’ll be able to improve that.