Mobile app for exploring bounties

[AhsanFazal]

Benefit to RChain

Exploring bounties and staying up to date with them becomes way easier and accessible.

Budget and Objective

Estimated Budget of Task: $[1400]
Estimated Timeline Required to Complete the Task: [10th of October 2018]
How will we measure completion? [App available for download in the Apple App store and Google Play store]

The Github repository: https://github.com/th3build/rchain-bounties-app

[tschoffelen]

I think we need the following functionality in the app to be on par with what is being created in #789:

• Filter by label
• See budget votes
• Vote
• Display open/closed status
• Commenting?

Ref for that can be found here, most of those things are already in the new web version that is being developed: https://github.com/jimscarver/rchain-tools

[AhsanFazal]

@tschoffelen Great idea, will implement those features.

[dckc]

Can this be done as a mobile-happy web site, please?

[ResonanceXX]

Kudos! This is nice, definitely good to have android/IOS versions for this.
Mobile phone penetration is ripe and plenty of limitations to mobile users would be removed.
RAMs from developing countries having access to important documents, even with basic cell phone/internet coverage - is a key change, to see.
If this improves interaction with shared files, its a very good project to embark on. @AhsanFazal Cheers.

[AhsanFazal]

@dckc Yep, sure can! I think the first step would be to build a general API for interacting with the bounties database as mentioned in #789.

[allancto]

@AhsanFazal what would you think of making this app show only bounties labeled "help wanted"? When issues are filed asking for help, they should be written in a way that is clear to potential contributors who may not already be familiar with RChain. That would keep us from broadcasting issues that are meant as internal discussion points or not yet properly formulated. @ResonanceXX @dckc @tschoffelen what do you think? A weak form of what I'm asking here would be to enable filtering (@tschoffelen 's suggestion) and have the default filter set to "help-wanted label" (which i still think would be too confusing but at least better)

@AhsanFazal if you can use the help-wanted label or create a new label or figure out another way to display only issues that are described clearly enough that potential contributors with no prior RChain experience can easily understand them, I will vote a $1600 budget for this work (which i personally consider awesome).

Thanks!
@allancto

[dckc]

The current Task Approval process is that budget votes are the way issues get approved. I support emphasizing issues with (a) any budget votes and (b) 3 trusted budget votes resulting in a >0 budget.

I prefer to leave help-wanted implicit on all issues. I don't think the Discussion label is cost-effective either.

[AhsanFazal]

@allancto great suggestion! I agree with @dckc that we should do this by putting emphasis on issues that are (on their way to get) approved by the community instead of relying on Github tags.

[allancto]

@dckc your suggestion of limiting to "approved tasks" is a good start but is not enough of a filter. Postings with potentially wide distribution need to be checked for accuracy and for intelligibility to potential first time contributors who are not already familiar with RChain internal lingo and discussions. Our issue template needs revision and clarification. Our system of labels needs review and improvement so that we're not implicitly encouraging for example translation and later telling people who believe they're done a good job and followed our guidelines that in fact they have not.

Since this does seem to be the job of the Task Approval Committee I recommend a simple solution. TAC should come up with a template for externally intelligible tasks which are not already completed or already have a full team, and a label indicating "Please Bid" or "Open Posting" or something like that. Issues which meet that communications bar should be published broadly.
cc: @dckc @deannald @patrick727 @lapin7

Examples of tasks which imo are not suitable for external publication:
#784 (already assigned)
#785, #616 (internal)
#786, "I meant collecting some of my thoughts on Governance"
.. (feel free to add your own set of improperly phrased or externally unintelligible issue statements here).

[deannald]

I would like to see a little more requirements analysis done on this proposal. If mobile applications are going to be developed and paid for by the Bounty System we need to ensure the following is addressed:

1. Is RChain as an entity registered in the various stores (Google Play, App Store)? E.g. who holds the distribution certification and provisioning profiles for these stores from RChain?
2. Who is managing the maintenance and monitoring of these applications? Bug fixes, updates, metrics of usage, etc.
3. Is this better suited to developing as a responsive web application, a progressive web application or a React Native application (versus native application development) - in order of complexity and maintenance? If so, who is hosting it?
4. What is the workflow when one clicks on the bounty - does it take them to a non-mobile friendly github page or are there more pages within the app itself?
5. If the target is to reach RAMs from developing countries, what versions of Android and iOS are we targeting - what versions of the phones are more likely used in developing countries?

I've got more questions, but these are ones I'd like to see people's comments on for now.

[dckc]

@deannald I had / have many of the same questions; @AhsanFazal contacted me about this work in discord, and he seems to have answers to many of them. He agreed to share a link to his source code in development here in the next day or so. I expect that will give initial answers to many of the questions. From there, we can continue story telling and test cases to refine requirements.

In particular, he's receptive to my encouragement to do something like a responsive web application. I hope we end up hosting it on rewards.rchain.coop.

@allancto the established Task Approval system is budget voting (the "Please bid" signal is reward votes). It agrees with you in the cases you cite; none of them has any budget votes except #616, which is sufficiently important that I'm comfortable with it getting as much attention as other "on their way to get approved" issues. I see nothing to back up your claims that things need to change, but feel free to make Pull Requests to refine ISSUE_TEMPLATE.md. Your suggestion that we're setting poor expectations about translation has some merit, but surely it's out of scope of this issue. If your edits are more than editorial, please open an Operations and/or bounty-contract issue for discussion.

[AhsanFazal]

I edited this issue to include link to the Github repository of the app. The README.md of the repository says the app uses the RChain bounties API but that's not yet the case. The development on this API just started.

My answers to your questions @deannald:

• @tschoffelen and me could take care of the matters discussed in your first two questions. We also built and are maintaining rchain.cloud. Of course I'm open for alternatives.

• This app is being developed as a React Native project right now. As @dckc has stated, I would love to develop a responsive web application in addition to the app to be hosted on rewards.rchain.coop. A general API is being developed as a data source for both these platforms. This was also discussed in User driven rchain bounty system dashboard development #789. This API will have documentation to allow any developer to have easy access to the data.

• When a bounty is clicked a native view is shown (not a web page) but there is a link to go to the webpage of the bounty as well.

• Access to metrics of usage and other metadata could be made available via the API.

• The initial target wasn't to especially reach RAMs in developing countries, but I really like the idea. Caching data for offline viewing and supporting older iOS and Android versions are the first two features I can think of that can be developed for this demographic. If anyone has any other features in mind for RAMs in developing countries, please let me know.

[jimscarver]

I think we can use community servers like rchain,coop, rhobot.net and rchain.divvydao.org that are cooperatively managed unofficial staging of apps that might become official rchain apps.

I think the issue of rchain account on google and apple is separate from this issue but needs to be addressed.

@AhsanFazal The desktop bounty dashboard team is interested in making the app mobile friendly. I am wondering if there can be any overlap with the native app development that might benefit both.

My votes go to cooperative activities more than individual accomplishment and would mush prefer that you work in a team. I think a better product will result have much greater benefit to the cooperative.

[tschoffelen]

I think the distribution is not an issue. Some of the tools that the Rchain community are using currently are community-hosted, so I think that would be fine for apps as well, with the ability for RChain to officially host them later. If @AhsanFazal is going to release this app, it will probably be under his personal name anyways, not claiming to be RChain.

The overlap in effort could come from the ongoing API generalisation effort, mentioned by @AhsanFazal above.

[JoshOrndorff]

What does a mobile app provide that a mobile website doesn't provide?

Of course anyone is welcome to build any tool they want, but a native-running app seems like overkill here. Please teach me what I'm missing.

[deannald]

@JoshOrndorff et al Unless there are specific on-device functionality requirements that can only be achieved with a native app, I would prefer that we stick with a mobile responsive app. Especially for something with such limited functionality.

[allancto]

@AhsanFazal in order to have this issue properly voted you need to give us guidance on whether there are team contributors (with %rewards), whether updates have been made according to the discussions above, and whether there is any anticipated maintenance.

I cast my vote for an overall $1600 budget based on my instinct that this is a tool which will get good usage within our community together with my (limited) knowledge of the cost of developing software like this.

@deannald @ResonanceXX @dckc @JoshOrndorff @jimscarver @Jake-Gillberg @aviationhacker @ian-bloom @AbnerZheng you're all people with expressed or potential interest in this project, once @AhsanFazal has clarified the reward%, update status and maintenance requirements I hope you will take the time to examine this work and vote it as you see it. Thanks! -@allancto

[ResonanceXX]

@allancto Well noted. Expecting plenty of good news from this as well.

[dckc]

After all the negotiation over budget, I don't see any reward votes; in particular, @AhsanFazal , none from you. Oh well... I guess we can get it right in the 201807 pay period.

[dckc]

@David405 , @jimscarver: and I just gave https://rewards.rchain.coop/ a responsive face-lift!

• 9f4b65c conf settings for better mobile experience w/JW,DA https://github.com/dckc/rchain-dbr/tree/prod
• 469690e https://github.com/dckc/xataface-responsive-theme

[allancto]

@AhsanFazal I hope you weren't "turned off" to contributing by the discussion previously. We DO value developers who see an opportunity and act on it. We DO understand that talented, energetic people have constant competition for their time. We DO want you to stay engaged and involved with us.

Thanks for your contribution! -@allancto

[dckc]

@AhsanFazal would you please update the Estimated Timeline Required to Complete the Task?

Two weeks from June 25 has long passed.

[AhsanFazal]

You're right. I stopped working on this for a while, but I will be continuing work starting today. I still have to fit the hours needed to finish this project into my own schedule and see what the deadline would be but for now the date is set on the 23rd of September.

[dckc]

nudge

I still see Latest commit 43bb66c on Jun 30. Sep 23 has come and gone.