(I love those random stock photos)
Hi,
It was discussed before,but now the core dev team decided to move forward with the changes, so we would like to hear about your thoughts:
proposal update operation
This is an operation to allow (at no cost) proposal owners to change some parameters for their proposals. This includes
- title
- permlink
- price
For the price an user can only decrease the amount, for obvious reasons. And if you voted okay for a proposal at 100 HBD, surely you are okay with a proposal at 90 HBD.
This solves the problem where someone submits a proposal that is deemed too expensive by stakeholders but then your only solution is making a new proposal which means having to ask everyone to re-vote on your other proposal.
Proposal creation price increase past 60 days
This one was discussed extensively here https://gitlab.syncad.com/hive/hive/-/issues/44
I'll quote blocktrades, the one who initially brought that idea up
For example, to create a post that "exists" (end_time - creation_time) for one year would cost 356 HBD (356 days). Proposer can increase their payout by 1 HBD per day to cover this cost (assuming their proposal gets approved).
This may encourage posters who are not sure they will get funded to created shorter term "milestone" type proposals (e.g. phase 1, phase 2, etc), instead of creating one post for the entire development interval. Of course, each of these subsequent proposals would need to be voted-in, but this would also allow for more oversight of the project.
In the end the change doesn't really change much, if you plan on getting funded, you can just add one HBD to your daily pay to cover this cost, and this prevents us from having anyone creating a proposal that will last 10 years constantly being displayed cluttering the proposal list.
We felt 60 days for the cutoff was a good amount, for most proposals. What do you think ?
I agree with the price of the proposal getting more expensive if it is made for a longer period. But a flat rate increase of 1 HBD per day seems lazy.
This would result in it affecting more modest proposals (in the 10-80 HBD per day range) far more than for larger requests. That's backwards. A proposal to let's say run an API like @anyx's proposal is exactly the type of proposal we would want to make a long-term proposal. For at least two good reasons. First, when the proposal sum is low, the cost of time needed to get support for one's continuously renewed proposal is far greater. Second, these are the proposals we should want to be more stable and reliable, and not require frequent updates.
On the other hand, proposals for high funding (let's say 250HBD+), are those we should want to do more short term proposals to have accountability and document progress. To those, the flat rate of 1HBD is very little compared to it's percentage reduction on more modest proposals.
Which leads me to suggest that it would be better if the added cost of creating a proposal is a given percent of either the total amount asked for, or the daily payment. This would also help offset what could be a likely outcome of your other proposed change: Where people are encouraged to start unreasonably high with their asks since they can always just lower it later anyway.
A better example would be for the added cost to be 1% of the daily payment requested. Thus, a 25HBD/d proposal would add 0.25 HBD per day beyond 60. While a 500 HBD proposal would add 5.
That seems both more reasonable, as well as more likely to result in preferred behaviour.
I'd personally feel this is a better system if a little more complex. (oh no a bit of math D:)
I agree, IMHO there is no sense in adding any more complex stuff like calculating the fee of a proposal. Higher fees will only discourage creating proposals.
Why should be a lesser amount or more expensive proposals better for HIVE?
Even if hundreds of proposals would be created on a daily basis - the good ones with community support will come to the surface. Front-ends can also be improved and make voting for proposals more convenient and easy.
I would suggest that we should care about more important stuff like governance. The current delay for voting on witness is just a patch not a real solution for what we have experienced before...
Yeah added complexity is always a cost. I'll concede that point. But I think it depends on the perspective. Let's put it like this:
If presented this way, and if the UI displays it elegantly as one enters the numbers in the proposal. Then I don't think it will turn people off that much.
Also, how many do we want to make 6-12 month proposals asking for 300-1000per day who don't already know the system well?
Frankly, I'd support strongly the fee for submitting a proposal to the community for approval or denial should be simply a percentage of the funds sought. Perhaps a very small anti-spam fee would be appropriate to prevent trolling.
But someone asking for 10 HBD a day can ask for 11 HBD instead. Problem solved.
That was only a small part of the problem.
And I don't think it solves it.
Hey, @howo.
Is there a post somewhere I can go and read what all is now included in the upcoming hardfork?
It seems it could include this, and the second airdrop for folks who were mistakenly left out, plus those who have been approved since. After that, I'm a little hazy on what else might be involved. Even if it's highly technical, it would be nice to know.
I've gone to github a couple of times to see if I could figure out what might be happening, but I'm afraid I didn't have a whole lot of luck. It's been a few weeks since the last time, so I could try that again if that's the only place to look.
I do appreciate the time and effort of all involved in keeping HIVE up and running. As far as these changes for the proposal system, I have no major objections, other than 60-days could be too short an interval for even milestone projects as blocktrades describes. However, I am in agreement that increased oversight and accountability with these projects are needful and necessary things.
Hi, most of the changes are on gitlab and we will have a release candidate around next monday then we'll compile all the changes, but we are mostly doing housekeeping with this HF tl;dr:
Thanks, @howo, for the reply. That all helps a lot.
re: converting steemit's stake
At one point, it sounded like there may be a community discussion over what to do with steemit's holdings. I guess a decision got made to just go ahead and convert it? I've been waiting to see what people thought about that since there were a few options as to what to do with it.
Don't count on that.
Hey, @oldtimer?
What part am I not counting on? :) That the decision has been made or that there could still be a discussion about it? Something else?
The decision was made without community discussion.
My remark was more meant for future actions.
I know they'll jump on me for this but let's face it;
decentralization and proof of stake don't walk together hand in hand.
Ah, okay.
Apparently, we all have our own definitions of what decentralization means—for some, it seems, around 60-100 persons involved out of thousands is sufficient, certainly better than 20-30, at least to start with—I guess we'll see moving forward whether that continues to be the case. For others, you can't have enough involvement, and I would imagine there are more points for folks in between.
I think a lot of this could be mitigated if someone were to regularly (once a week would be nice, like hiveio did for a bit), communicate, but while some individual devs have been popping up here and there, we don't seem to have regular and consistent updates from the main blog.
So, we're left to piece things together. Which, unless I'm getting this wrong, was one of the many knocks on Steemit Inc. for such a long time.
I'm not sure how I feel about using the 'ninja-mine' stake. I guess I'm just not used to creating something out of nothing, even though that's the way things have really worked since man began to barter.
A two month search for funding seems to be a reasonable time frame. The increase of the cost of submitting a proposal also seems like a good method to keep spammy type proposals off the system and to reduce clutter.
Most business operate in a quarterly fashion, if an update post of the progress being made is not completed in a timely fashion, then on all subsequent proposals from then that should be appended somewhere to let the voter know that this particular team did not keep the voters updated with standard progress reports.
A main concern with the proposal creation price increase is whether it will discourage some people from creating proposals that could be valuable to the ecosystem. It seems that currently, for anyone who is not well established and known, it would take a while to reach enough support to get funded. This means more than 2 months. So I think the cutoff at 60 days does not correspond with current reality which is that it can take more than that to get above the return proposal.
What is our goal here? From my view, it is to invite valuable proposals from anyone, regardless of the proposal size and whether the person is known. And to discourage spammy proposals that don't bring value to the ecosystem. From this point of view, it makes sense to me to start with less stringent proposal creation fees and increase them only if there is abuse/spam proposals.
From this perspective (starting from less stringent and moving to more stringent only if need be), perhaps if the cutoff is at 90 days and/or the amount added is 0.5 HBD per day (or even less), we will be safer in thinking that no one will be discouraged from submitting a valuable proposal, and that at the same time spammy proposals will be discouraged.
You are not supposed to have your proposal started while seeking support, this is why you can set the start date to be in the future. That way you can get votes while the proposal is not "running".
That's what I usually do, I know it takes about a week to 10 days for me to get enough support, so I set the start date 10 days in the future, so that when the proposal starts I am over the return proposal already and I don't lose payouts. And the number of days is end date - start date so that would be fine.
On your other thoughts:
if you are not known, I think it makes a lot of sense to make short proposals for 60 days, then another one to grow your reputation and increase the chances of getting to funding (I know stakeholders feel more comfortable funding 60 days proposals than 360 days ones)
Can start date be changed too? Like earlier if enough vote and later if not enough?
I think that can allow for the system to be games. If the total you are seeking is 100 HBD, at 1 HBD/day, with a start date of a month away, and you get enough support on day 1, you can just move the start earlier and get an extra 30 HBD. Now its up the the voters to unvote if they notice irregularities, but whats to say everyone is keeping an active eye on it? I think this is a no.
Moving it later on the other hand, that I do support.
But what if by changing the start date, the end date is also shifted accordingly?
Well then you'd need to allow moving start end end date, otherwise you're just reducing your rewards, and at this point you got the same problem with "infinite proposals being there forever"
I'm not a fan of the fixed daily fee for unfunded proposals. YES if it would get funded you might get it back anyway by pricing it in. But we also know newer teams without a lot of support behind them 'automatically' will have to pay a higher price then if they somehow get a lot of support but just not enough for not making the return proposal. I don't think there should be a 'fee' for 'not making it'. I don't think we want to discourage newer teams who have to work harder than all the familiar names who will get funding easier. We want to encourage newer teams to add proposals, maybe not make it, learn from it, and make a better proposal next time. But we don't want them to not make that proposal and have that learning experience because they know they have to pay more than those who will make it from first attempt.
I do think that having a technical or otherwise frontend solution for proposals 'fall down below the fold' (visually less prominent in the proposal list) will help keep the DHF a clean experience.
In general my view on this is: let's not make Hive all about money/paying up beforehand, but also give smaller users a chance to work their way up through skills and/or education.
Just my 2 cents because you asked for input. Cheers.
I totally agree!
And I thank you for your input :)
On the cost for unknown teams. this is why we put the 60 days thing, the idea is that there is little chances that a "not well known" team might be successful in managing to get their proposal to funding before they had a track record of smaller proposals first. And ideally proposals should be done by milestones like "proposal 1 to achieve x/y/z, with the budget I will fund x for y$ z for k$" etc
While preventing abuse is good and all what I'd like to see sooner with regards to the proposal system is better filtering and display of proposals.
Currently it's a bit of a pain to view proposals and search through them by catagory or something.
Perhaps a proposal should be made to standardise how proposals should be made and also add a way to categorise them. Like I donno Hive, 3rd party app, Mainteance cost. etc.
Alternativly come up with a recommended standard for tags to help with finding proposals you are interested in.
I guess this is more of a front end issue, that could be solved relatively easily with a standard on proposals.
I consider these fairly "lazy" changes and disapprove of the second one.
See thats a very wrong way to go about it and im fully aware why you took that route. This effectively changes nothing since support for proposals is based far more on popularity then it is on expense for funded proposals. If you can get funding for 50 HBD then you can get funding for 100 HBD.
Coming to the conclusion as the proposal maker that something is deemed too expensive involves guesswork, probing feedback and more often then not (almost always) how expensive your proposal is doesnt really matter right now and with your change.
With what i propose, the expense would matter, as should be the case!
Heres what you do.... (which im pretty certain none of you will support)
You introduce a voting slider that would vote a proposal only for the percentage you think the proposal deserves funding
So if you think the proposal maker deserves 30% of funding, you select on the voting slider 30% and the vote will be automatically canceled after the proposal has been funded for 30% of its days. Basically just coding in an unvote command after set days.
This would change a lot of things. While you could say "well just click unvote after set days".
We know that doesnt work that way and the way that people perceive the proposal voting and voting sliders is very significant.
This would encourage people to give lesser known proposal makers a chance to start up their funding, see what they come up with and if they will deliver. Why not give them a chance for a couple days?
It would also bring much more competition to the top spots reserved for the 4-5 of you.
If you're asking your normal rate for a job, and I'll tell you that I'll be paying you 30% of that, would you still do it? Not persé because of the money, but because someone is saying you're 30% worth the normal rate that your other clients pay you.
We must understand the value that it brings, and not judge the amount of what is being asked for. Based on credibility, prior achievements, set of skills and experience, person X is charging X, whether you like it or not. It's rude to say it's worth 30% and pretty ignorant since we don't have a clear understanding of their living conditions, expenses, or already invested time to be able to do what is being proposed. You can (and should) only judge the value it will bring and compare it to what is being asked for as funding. And if the funded ask is more than the value it will bring -in your opinion-; you simply say "No, thank you, this proposal is not for me".
Hes asking and i make the call on how much i think he/she deserves. The funding starts, its payed daily and the vote slider cancels your vote after 30% (or whatever) of the time.
I can say i value someone work at however much i want to value it.
Your objections are strange and dont really have much to do with my suggestion. This would be an additional option that would do good, you dont have to use it if you do not want to use it. Just click 100% every time.
Seems youre objecting for the sake of objecting.
"Seems like you're objecting for the sake of objecting"
Ah, you wanna play... okay :). For the sake of common sense and logic, I'll try to explain.
First off, I think your starting point in understanding what a proposal is about may be a little bit off track, which makes it hard for you to see/understand that your suggestion is rather obsolete and an option that disrespect applicant requests.
Secondly, the purpose of filing a proposal is to improve the blockchain, right? To be able to measure the amount of funding that is needed, the applicant has to calculate the time and resources it takes and cost. Depending on someone's experience, expertise, and skillset, they require to ask an hourly rate accordingly to that.
What you're suggesting, is the same as bargaining on a marketplace, except you're demanding a 70% discount, which is rude and ignorant. A problem that arises with your suggestion is that if everyone can say that they want to fund it for 5%, 10%, or 40%, the applicant will never get 100% funded. You simply cannot question someone's pay rate, but you can decline, or agree with it.
Lastly, a proposal is not about what you think a person deserves. In fact, it has nothing to do with what you think a person deserves. It is about the content of a proposal: cost/product. Again: if asked-funding equals and requires 100% and you want to fund 30%, you can't expect a 100% return as 100% is required. Unless you're okay by having an unfinished product.
I don’t really have anything to disagree with (even though I tried to get into that position as a mental exercise). I approve those changes!:D
Hey Howo, what is the goal of applying these changes? Is it just to decrease proposals that are lingering out there not being active? If there are more than a few goals, please let me know about all of them :). Perhaps I can run an analysis on it, and try to see if I can come up with a solution that covers a portion of it.
Adding a fee to create a proposal wouldn't be a bad thing, however, an ongoing fee for X time is something that I consider to be limiting those who wish to contribute to the blockchain and find 1 HBD too much of a risk. As far as I'm concerned, proposals should only be funded if it brings value to the HIVE blockchain.
Therefore, if someone is bringing value to the blockchain, I wouldn't ask them to pay for sharing and execute their ideas ongoingly while risking that their proposal isn't going through.
Some thoughts
If people don't know how to write a proposal, perhaps with the right questions and fields, this could be resulting in having more proper and well-thought-out proposals. At least, I would find it odd if one submits a proposal that isn't planned out prior to submitting. Even with 1 HBD or x% fee, there would still be a chance to get the same in-active proposals we're dealing with today.
If proposals are not being funded by X time, execute a kill on specific proposals, whereas applicants could both address the time-frame when their proposal should be funded or killed. An example; "I'm willing to propose this, and unless this proposal doesn't get funded in 60 days, I either: kill the proposal or re-apply the proposal manually in the nearby future."
If a permalink is something that you can edit as an applicant, wouldn't that risk change of the rules in a proposal? Of course it is possible to look it up in blocks what was written prior to any change made. But if I voted for a proposal that didn't get through yet, maybe I wouldn't want to vote on it with a changed set of rules.
Cheers,
Ruben
I suggest there are potential for proposals that do not require financial support that the creation fee may prevent being proposed. There should be no fee to propose something that seeks no funding, but for which it is appropriate to seek public input and approval.
Having skin in the game is quite appropriate when seeking a pound of flesh, but requiring it for non-financially rewarding proposals is counter-productive.
Thanks!
What's a proposal?
A single proposal is a request for funding basically, the proposal system is something on hive where individuals or projects can ask for funding, and if enough stakeholders support it, they get funded by the chain directly, money comes directly from hive's inflation.
You can see more at https://hivedao.com.
Cheers, nice!
Is there a subproject that manages applications?
everyone manages applications :) anyone can vote on proposals if they think it should get funding.
Thanks, my point is whats the process to submit an application. I'm aware of the hive blog/social network and it's the first time I've heard of this aspect of hive.
I like with the changes. For those who say that the proposal from @anyx will get hurt, well he just needs to ask for 21 HBD daily instead of 20.
Oh the change is only for future proposals he would not get hurt.
Well, the point is that future proposals similar to that of @anyx might get hurt. If someone makes a proposal that lasts for 1 year, then that is an investment of about 300 HBD. The person then would have to expect that they will get that money back. But will they? @anyx's proposal remained unfunded for a long time. So the requirement of an upfront investment of 300 HBD might discourage the person from submitting the proposal, if they are unsure whether they will get this investment back and cover the costs of their work. Remember that proposals usually don't get 100% funded. So it's not as simple as adding 1 HBD per day to your proposal asking amount.
After 60 days the initial costs for the proposal increases by 1HBD per day?
Seems appropriate.
Those changes are ideal and needed around this. I think it's expedient as redundancy can lead to a spammy look.. if HBD maintains as a stable currency it's only obvious that funded proposals increase in value as we are in a world of increasing inflation.
Proposal update is 100% good especially option to decrease funding required.
Proposal Price increase just makes things more complex without significant benefit. Keep it simple.
Hope it brings positive things
This I can get 100% behind.
This doesn't address any changes that are actually needed. No thanks!
I really enjoy this outreach to the community for feedback on such changes. I do think that it would be even better if there is a more standard way of doing it, like issuing all such requests for feedback from a dedicated account, e.g. @hiveio. This helps with communication as there is one "official" account that people can follow to get all such important communications. So the feedback request reaches more people and more of the community can give its input. The people who follow e.g. @howo may be more of a dev type people, and other types of people may have different perspectives.
Jiggling with price and time to fit the best proposal could be great instruments with moving forward. Uncluterring the list is another thing to keep new things on the map and new ideas coming in. I would jump for the proposals.
What do you propose that we do instead (aside from deleting it)?