Soledger Inc. (myself and @Agent86) is proposing a BitShares worker for handling administrative and maintenance tasks including--but not limited to--the following:
- Emergency security patches
- Emergency network stability patches
- Merge upstream Graphene, fc, other library updates
- Fix important compilation and compatibility issues
- Tag core releases
- Manage GitHub issue tracker
- Manage GitHub pull requests
- Consolidate high-quality community projects into BitShares GitHub organization
- Consolidate and maintain other important documentation to help ease contributing and integrating
Vikram - I don't mean to quench your enthusiam, but like others have already said, the software has been *very* stable, which means that there is no immediate need for any of the above. You've set up a worker that pays $1200 per month - for essentially nothing.
Also, I find it a little strange that someone with little knowledge of Graphene turns up after a year of absence, and the first (well, second actually) thing they do is request full access to the main GitHub repo.
I know you're a very capable person, but I would still prefer a more gentle approach to things. That would allow the community to evaluate your work, and give you a chance make yourself familiar with the new codebase. If we reach a point again where BitShares sees more or less regular updates, with your help, I will certainly approve your maintenance worker as proposed above. But not yet.
I definitely hear your concerns and perhaps we should have reached out to you directly before attempting to finalize such a proposal. And perhaps I should have also been more descriptive in the OP:
- Emergency security patches
- Emergency network stability patches
Ideally these would never require any work. However, if such an issue were to arise--which may happen unexpectedly at any time--I think it is important that a specific party has responsibility for ensuring that the issue ultimately gets resolved.
- Merge upstream Graphene, fc, other library updates
This may be a combination of minor things, but something that I want to make sure is maintained well nonetheless. I note that bitshares/bitshares-2/bitshares has diverged from cryptonomex/graphene/master after commit 006d54863312c7daf1ccb73d5940ec658c860efb and has diverged from cryptonomex/graphene/develop after commit f049fce4e97154ce0d037ee2818a285ebffb944f. bitshares/fc has also diverged from steemit/fc after commit 0dca15c3954d38f2a8603aab316d214ca893930f. The updates themselves may not be particularly important but I think it points to a lack of organization in that these divergences persist.
I am also interested in backporting other base Graphene fixes from Steem when applicable and permissible. I also want to look into the feasibility of backporting an upgrade like ChainBase (
https://steemit.com/steem/@steemitblog/announcing-steem-0-14-4-shared-db-preview-release) should it be successfully integrated into Steem.
- Fix important compilation and compatibility issues
Ideally this would never require any work. However, operating systems and environments continue to update and move forward, and it may become more difficult to contribute to or run BitShares as time goes on. As an example, I am unable to compile BitShares on my local machine running Arch Linux, presumably due to compilers or libraries which are too new. Perhaps nobody needs specific responsibility for issues like this, but it is something that I intend to keep track of and try to address when possible.
- Tag core releases
Perhaps I misunderstood this initially; although
@svk has been tagging what are marked "GUI Release"s, they indeed incorporate all of the few changes to the core code that occurred as well. I do not want to interfere with his work. However, if in the future, there are non-trivial changes to the core code, I am willing to perform final reviews of all said changes before signing off on an official release tag, as I previously was responsible for with BitShares 1. Further, if there are significant updates in the future, someone should also be responsible for coordinating and notifying exchanges and other service providers, a step which has had oversights in the past.
- Manage GitHub issue tracker
- Manage GitHub pull requests
- Consolidate high-quality community projects into BitShares GitHub organization
- Consolidate and maintain other important documentation to help ease contributing and integrating
On second look, I am not yet sure on the best path for the issue tracker. If it seems that bitshares/bitshares-2 will continue to diverge from cryptonomex/graphene, perhaps it does make sense to open an independent issue tracker for bitshares/bitshares-2. This can also be used to collect BitShares-specific issues and should also be more discoverable for BitShares users who do not understand the Graphene heritage.
There are also outstanding pull requests in cryptonomex/graphene, cryptonomex/fc, and bitshares/bitshares-2. The commits may ultimately be inconsequential, but again I think it points to a lack of organization that these requests sometimes go unaddressed. I want to make sure that potentially valuable issues or contributions do not fall through the cracks.
I will have to do more of a survey of projects to get a better idea, but I was thinking that projects from community leaders such as
https://github.com/xeroc/python-graphenelib,
https://github.com/xeroc/graphene-paperwallet,
https://github.com/svk31/graphenejs-lib,
https://github.com/svk31/graphenejs-ws,
https://github.com/kenCode-de/bitshares-wallet,
https://github.com/kenCode-de/smartcoins-wallet as some examples, could potentially be moved into
https://github.com/bitshares if said owners find it suitable, to consolidate pieces of the BitShares ecosystem more clearly under the "official" BitShares name.
I will also have to explore the state of documentation more, but I want to look into consolidating and updating info from places like
https://bitshares.org/,
http://docs.bitshares.eu/,
https://bitshares.org/doxygen/,
https://github.com/bitshares/bitshares-2/wiki, or at least try to help organize things so that relevant information is more discoverable.
In general, I will also do my best to address relatively clear issues that arise if and when possible. As an example, while syncing a new node yesterday my p2p logs ballooned to greater than 35GB. I can't say that fixing such an issue will be straightforward, but it is the kind of clear problem that I will look into.
Again, I hear your concerns but I hope I have clarified my thinking at least somewhat. The system has indeed been stable and hopefully will remain so, but I do not think these responsibilities amount to nothing. In a system as large and integrated as BitShares--still around a $10 million market cap--I think it is important that even the small details are taken care of. If BitShares were to rise dramatically in value, I think it is even more important to pay attention to the details.
I indeed have relatively little experience working with Graphene, especially after the time that has passed, but I am not wholly unfamiliar with its design--I was there when it was first built and made a number of commits (
https://github.com/bitshares/bitshares-2/graphs/contributors) --and am confident in my ability to get back up to speed.
If I recall correctly from when I previously stepped down as GitHub admin, at the time the only other admins were Cryptonomex, BlockTrades, and maybe
@cass. If no one else has been added since, it seems like there is room for additional active community leaders to be given administrative permissions, which I would want to grant to probably at least
@xeroc and
@svk--if there is no great objection to me adding more admins. I will edit the OP to mention this, but it's a natural extension of consolidating community project repos into the GitHub organization. Part of the intent of this worker proposal is for stakeholders to vote on assigning administrative authority to a new party. BitShares is a decentralized project and will continue to have different people in different roles as time goes on.
I hope I have made my thinking a bit more clear. Thank you for the honest thoughts and consideration.