Ideas, Proposals and Concepts for Future versions
The purpose of this part of the wiki is to list all the ideas, proposals and concepts that might be included in future versions of the Giveth System. However, we do not guarantee that any of these ideas will be included.
It would be useful to add multiple locations to where the DACs, Campaigns and Milestones are happening or are located.
The proposal is: 1. Pick exact locations (e.g. Address or GPS coordinates) 2. Pick a country 3. Pick a continent
If the user picks an exact location, the country and continent is automatically deduced. If the country is chosen, the continent is also automatically deduced. Because DACs, Campaigns and even some milestones can be in multiple locations, the location field should be a list and not just a single location. However, there should not be an automated 'inheritance' where the DAC would inherit the locations of its Campaigns.
Map Preview of a Milestone with Location: Example on how Milestones could be visually represented on the map.
Assuming each DAC, Campaign and Milestone has a location set, as described in Locations of DACs, Campaigns and Milestones, all these entities could be searched on a map or on a 3D globe. In a DAC you could see to which places the delegations goes and in Campaign the user could see where the individual Milestones took place.
Example of 3D visualisation to see where geographically a Campaign is making a difference. The concept image is taken from D3js example page.
Example of 3D visualisation to track donation flow geographically. The concept image is taken from D3js example page.
Giveth already has a lot of information that is not in use yet. By analysing the transactions, we can easily build graphs that would help people understand where the DAC's money go to and where the Campaign money comes from.
Where is the Education DAC spending money? Each DAC shows which Campaigns and Milestones are funded. By clicking on each of these the user would get a table with all Campaigns and how much % of the DAC money was delegated to them. The blue elements are DACs, red are Campaigns and green Milestones.
|We help kids||Campaign||35%|
|Shool in Zambia||Campaign||20%|
|It Teacher Salary||Milestone||12%|
|Learn to code||Campaign||10%|
|Purchase Graphics Software||Milestone||6%|
|Buy equipment for Computer Lab||Milestone||4%|
|Internet bill February||Milestone||3%|
|Internet bill March||Milestone||3%|
|Internet bill April||Milestone||3%|
|Internet bill June||Milestone||3%|
|Installation of new language education software||Milestone||2%|
|IT olympics for High School Students||Campaign||1%|
Where is the Campaign getting funding from? The blue elements are DACs, red are Campaigns, green Milestones and white starts are users.
For most people, even the ones already invested in cryptocurrencies, it is difficult to evaluate the fiat value of a certain amount of Ether. Therefore, it would be great to provide a way where they can name a second (fiat) currency to Ether, to use alongside or replacing the system's Ether values. When donating, they could say "I want to donate 100 USD", instead of having to put in the value in Ether. Because we know the exact moment a transaction is happening, we could easily (given acceptance for minor rounding errors) display how much money any past donation was in fiat. This is especially necessary if Ether rapidly gains or loses in value as it becomes unclear how much money a Campaign or DAC had and could lead to a confusion where Campaigns could look overfunded due to dramatic price increase.
Donating an amount of Ether expressed in fiat currency. The actual donation would still be in Ether, but the value could be expressed in Ether based on recent average value from some major exchange.
|Amount ETH||Est. Amount USD||Date||Name|
This example illustrates a snapshot of past donations and how it could look with value estimated in a fiat currency. Note the significant price change between the last and first donation in the list.
Comparison between monthly expenses in ETH and in USD. Example on how it can be deceiving to use Ether vs how much money is actually spent. The data shown here is taken from the Giveth budget.
Currently it is not clear what a Campaign spent their money on. Should users decide to gain this insight, they would have to read through all the Milestones and maybe even then it would not be clear. Adding spending categories could help: Both the Givers and the Makers, gain the ability to evaluate what the money was spent on. The list of categories should be predefined by Giveth and new categories should be created on request. The overhead for the user consists of selecting a category from a list when the milestone is being created. Usage of this feature should be optional.
Overview of spending for an example Campaign. The aim is to provide Givers and Makers with a better overview on how this Campaign is spending the money.
Even now, the system contains enough information to provide some simple accounting, analytical and business intelligence information. Analytics do not need to be part of the Giveth platform, but could be plugged-in via an external tool. Note that some of these tools work best if the value is expressed in a stable currency. One option to mitigate the stable currency problem is to integrate the Real-time and Historical Fiat Conversion proposal.
Here are some examples of what could be achieved with this feature:
- Daily cashflow of the Campaign
- Donation frequency
- Average amount
- Target DAC audience
- Donations and spendings per day/months/years
- Spending categories (Assumes system has Categories for Milestones)
- Recurring Givers
- Spending breakdown at Milestone granularity
- Amount of time required to raise funds for Milestone
- Future forecasts
Example of overtime balance graph. The data is taken from the Giveth budget. Note that this graph does not reflect actual value all that well, as one can easily see the actual value spent in Ether was 60 times lower before March 2017.
In the Giveth MVP there is one Delegate per DAC who is the owner and the only person that can delegate donation. The tension is that should the Delegate be unavailable (temporarily or permanently), the DAC will just accumulate donations that could be already making a difference. In addition to that, bigger organisations will need multiple people being able to delegate money. One solution would be to enrich the Delegate role to be able to nominate other Delegates and build a governance system in the DAC. It could then be up to the individual settings of the DAC to define how many votes are necessary to:
- Nominate a new Delegate
- Remove a Delegate
- Change the DAC information (description, DAC's name,...)
- Delegate Donations
- Freeze a delegate
As an example, we can assume following setting for DACs:
- At least 51% of DAC's Delegates to nominate a new Delegate
- At least 70% to remove a Delegate
- At least 30% to change the DAC information (description, DAC's name,...)
- Everyone can delegate without the need to vote (0 votes on donation delegation)
- Everyone can freeze a delegate and the freeze time is 3 days
Freeze: We propose a 'freeze' user action, which can be called by any delegate to temporarily freeze another delegate. Frozen delegates can not take any actions until they are unfrozen.
Use case diagram for Delegate role if the DAC Governance is implemented. The white actions are about changing the DAC's information, green refers to donation delegation, blue are security actions, red are actions to remove delegate and the yellow shows new delegate nomination actions.
Use case diagram for automatic actions if the DAC Governance is implemented. Should there be delegates that did not vote yet, all their votes go to: - Support the DAC modification - Support donation delegation - Support nomination of new Delegate - Oppose the removal of a Delegate.
If the delegate is frozen for longer than the time limit, he/she is unfrozen.
Delegating from DAC to DAC
Mobile Wallet integration
Wallet Recovery System
DAC, Campaign, Milestone Search and Filtering
Exploration based on Donations and Delegations
- Instant messages..