The proposal system introduced in the HF21 is a big improvement and step forward in the blockchain. Thanks to this Steem is now a bit more auto sustainable in terms of developments and contributions.
In this sense, I also want to give my contribution. The objective of the current proposal is to improve the steem code, concretely, the proposal system itself. Although the work done by 
The improvements I propose to develop are:
Currently, when a user votes for a proposal he is voting with all of his steem power, there is no way to define a weight.
For big stakeholders this is a problem. Suppose this situation: A big stakeholder votes for a return proposal and votes for a proposal for a new development. He really wants the new development but it is not reaching the threshold. If he removes the vote from the return proposal then the development will start getting the funds, however, the return proposal lose a lot of votes and then other proposals can cross the barrier and get funds too.
This problem can be solved by giving the possibility to vote with different vests. In this case, the stakeholder could reduce the vote for return proposal a little bit in order to reduce the threshold for the development but not too much and the barrier continues for the rest.
Suppose this scenario: A proposal is created to work during 15 days and asks a daily payment of 100 sbd. Then the expectation is to to receive 1500 sbd. What happens if at the end of the period the total payout is only 1000 sbd? There are some ends in the current implementation:
One solution to these problems is the possibility to define a maximum payment. Following the example above, the contributor could create a proposal to work during 25 days, ask a daily payment of 100 sbd, but put 1500 sbd as the maximum payment. In this sense there are 10 additional days to complete the payment, but it can not increase beyond 1500 sbd.
In the current implementation the unique way to calculate the total paid to an active proposal is by consulting all single payments using the history api.
If we implement the maximum payment described above, then the total paid must be added too, and it can be easily obtained by calling the proposal details.
Currently, each hour, all votes from all active proposals are computed in order to sort them and distribute the payments.
If a single proposal is voted by 12000 users then, each hour the blockchain will add the steem power of all of them, which is not scalable to hundred of proposals and thousands of users.
The best way to handle this issue is by calculating only the increments. If a new vote comes in, then the total is incremented. If it is removed then the total decreases. If there is a power down then the proposals voted decrease. If there is a power up the new vests are added to the proposals voted.
In this sense, after the end of the period there is no need to calculate the votes, just sort them and distribute the payments.
This part will also solve the current problem with the inactive proposals, which the total votes are not calculated because the inactive proposals are not in the schedule of payments.
The total payment for this work is 4800 sbd, distributed in 30 days with daily payment of 160 sbd.
The new code will be submitted as a pull request to the principal repository of steem.
I've been working as principal blockchain developer in a pilot project for the European Commission during almost one year. This time has helped me to get a lot of experience with respect to the core of the steem blockchain and I would like to continue doing more improvements.
I've made some minor contributions to the steem repository:
I've been contributing to the dsteem javascript library:
To vote for this proposal follow this link.
To consult this proposal:
These ideas are the result of discussions with some users and witnesses, especially 
