|BitShares UI Team|
|Total||up to $ 107,380|
|Duration||2020/03/25 - 2020/09/29 (26 weeks)|
|Worker ID||1.14.256 (click the id to vote with Beet or go to reference UI)|
|Accounting & Reporting||workers.bitshares.foundation/202003-bitshares-ui|
As the first and quite a long time only user interface (UI) for the BitShares Blockchain, the so-called BitShares UI has established itself as the reference for other visualizations. It provides by far the most complete list of features available within the backend of the BitShares Blockchain, presented in a point-and-click style of way for users not familiar with command line interfaces. On top of that various second level uses like Signed Messages and Asset Bartering are available.
The BitShares UI is often called the Reference UI. And it seeks to be exactly that: A reference that seeks to showcase any and all features that the BitShares Blockchain offers. Easily onboarded, forked and branded. The idea is that gateways or business have an easy entry-point and to be able to give them sample code on how to interact with the blockchain. The idea was not to provide a simple, slick, use-case targeted UI for depicted target groups like traders.
Anyone should be able to get a grasp on the feature set while being able to quickly try things out. The user experience is of course always one key driver for development of the BitShares UI, but it will never be as simply or focused as a tailored UI with a specific use-case in mind.
This worker will last for half a year, starting from 9th of March 2020 (Calender Week 11) until 13th of September 2020 (Calender Week 37).
As previous, the worker will be used to support development on a number of BitShares repositories. These are the main repositories (others may be added in the future). Beet is a stand-alone, multi-chain key/identity-manager and signing app for BitShares.
To decrease costs for the worker we will no longer include any community bounty payments, nor any travel funds to conferences. The cost will be focused on experienced developers that know the code well enough to make good commits to the code base.
Aim for release schedule is every 12 weeks (i.e. two releases for this worker). It will be based on six sprints, each 2 weeks. During the first four sprints the team will assess and work on new features, enhancements and improvements that can be finalized within the release. The last two sprints will be focusing on testing, bug fixes and fine tuning before the final release. All efforts for a release are organized and reflected in GitHub as “Projects”. Each task will be reflected in GitHub as an Issue.
Critical bugs will always take priority, and hotfix releases may be released inbetween if required. In general, releases may be delayed depending on test results to ensure only polished releases are published.
The roadmap for this worker will contain three main parts:
Integration of Beet and seamless user experience
The biggest concern for users when interacting with a use interface is security of their own private keys. The BitShares UI offers cloud login (account and password) and a local wallet. Very common in the crypto space is the use of external key managers and completely extract the issue of key security from the website / light wallet. For the BitShares UI that means to enable a new way of logging in with Beet, a standalone key manager tailored for Graphene Blockchains, and possible other key managers like Scatter. That way the user only has to trust his private keys to the key manager that can be installed locally, and the private key is never exposed to the website requesting the key.
Maintenance of the code base (security issues, bugfixes & small UX improvements)
Keeping the UI usable and secure for the users is certainly a top priority. Especially in the crypto space, outdated software, libraries of bad (formerly best) practices can lead to severe consequences with loss of funds. NodeJS dependencies need to be maintained and bugs that surface fixed. On top of that, small tweaks on the right end can greatly facilitate the user experience.
Implementation of features/changes of upcoming BSIPs as they become available
With feature and api releases of the BitShares Core adjustments and/or extension to the JS codebase is necessary to keep up with the development. This may range from performance improvements allowed by new core endpoints to new features enabled through BSIP development. In particular for now:
While the last two parts are an ongoing basis, the third one is a defined milestone. In particular, that means that the actual development for 2, 3 is dynamic and needs contant evaluation whereas the integration of Beet for 3 is a fixed goal to be achieved within this worker.
Remark on Prioritization
There are many opinions across the BitShares community about what is most important. These opinions vary due to the broad range of individual capabilities. Some users want to see new features developed as soon as possible while others would like to see a refined user interface with reliable, less ambiguous controls and helpful documentation.
Engagement towards the chinese community will be strengthened and feedback collected.
Release planning will happen before the development. The feedback from the community and BTS holders will be heard and accounted for reasonably in the chronological order of the roadmap and releases.
The following are the main team members. The team may have more members during the course of the worker that do development.
Duties will be to create and coordinate release schedules, prioritize issues with developers and development.
Duties will be development, to review submitted PRs together with developers and coordinate new releases at the end of release schedules.
Duties are to review and approve submitted timesheets, as verified by closed issues or merged PRs (referred by the invoices).
Duties are to sync and review progress and discuss priorities for inter-team efforts. This is paid by the core worker, if voted in.
Duties include testing of release candidates and development builds, writing of bug reports as reported through GitHub issues and development.
All committed developers will coordinate efforts to follow prioritization of issues for the current release based on requirements needed for following the schedule set. At the start and end of all milestones the developers should make sure they follow the plan set out for them. Bounties are not free for all, and in case there are applicants only hand-picked motivated developers that finish the tasks will be added. Failure to finish within the agreed timeline may result in loss of compensation.
Budget includes fixed positions and development costs
|Role||Rate (USD)||Team Member||Estimated Hours|
|Project Manager||$80/hour||Magnus Anderson||up to 2 hours weekly|
|Code Review and Release Manager||$80/hour||Stefan Schiessl||up to 4 hours weekly|
|Funds Manager||$50/hour||Alex M||up to 1 hour weekly|
|Commmitted Development||$75/hour||Stefan Schiessl||8 hours weekly|
|Commmitted Development||$75/hour||Magnus Anderson||8 hours weekly|
|Commmitted Development||$75/hour||ety001||16 hours weekly|
|Commmitted Development||$75/hour||bench||8 hours weekly|
|Development||up to $75/hour||- Split between all developers as needed -||up to 8 hours weekly|
|Total||up to 56 hours weekly|
In total for the 26 weeks this worker is seeking for $ 107,380.
The daily payout is set to 36,610 BTS, which contains a devaluation multiplier of 1.1.
Payment cycles will aligned with sprints. This way the BTS holders can have a tangible and visible overview of the spendings.
Funds Manager will review and approve submitted time sheets, then forward invoices to BitShares Blockchain Foundation for release of funds from escrow to contributor’s account.
The payments will happen preferably in bitEUR, but may also happen in any alternative BitAsset, BTS directly, or in BTC depending on market conditions. The value indicated here and on later invoices represent FIAT values, and will be paid in equivalent value of the chosen crypto-currency.