Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show required amount and money already received #15

Closed
kirstin opened this issue Aug 25, 2016 · 5 comments
Closed

Show required amount and money already received #15

kirstin opened this issue Aug 25, 2016 · 5 comments

Comments

@kirstin
Copy link

kirstin commented Aug 25, 2016

Every Project or show on TV has a certain amount of money they need to produce whatever they produce. If the money exceeds the required amount of money a lot the money cannot be put to good use in this project. More money for the show/project does not necessarily mean there will be more shows of that type or it will have a better quality.

I propose:
Each show/project can submit or has a required amount of money they need to produce the show./work on the project (Maybe this can be more distinguished as well, "amount required", "amount wanted", "maximum amount usable in a reasonable way")
As Users distribute their Rundfunkbeitrag they see how much money each show is already receiving (and whether the threshold is crossed).
This allows users to distribute their Rundfunkbeitrag not only paying attention to what they like but also to what each show needs. This allows the users to give their money to a show they like, which is not their favorite, because the favorite has already received enough money.

This opens up the possibility for users to influence the program a lot by not supplying shows or projects with the minimal required amount.

@roschaefer
Copy link
Owner

Thanks so much for your feature request! I opened a pull request to show you how I understand it. Would that satisfy your requirement?

@roschaefer
Copy link
Owner

I want to mention that this is going further. I did a small survey with 10 participants and a user test with a paper prototype. Here is the result of one question:

production_cost_survey

Reason is that some people believe production costs should not influence your decision. I am considering to let people turn-on/turn-off this feature (displaying production costs).

@roschaefer
Copy link
Owner

Another question that comes to my mind: If many users take money away as the broadcast has sufficient funding, does that conceal in some way how much a broadcast is loved in spite of that?

@kirstin
Copy link
Author

kirstin commented Aug 28, 2016

I believe there is an important distinction between production cost and a fundraising goal. Of course they are connected. Also there is a variance in how much it costs to produce a continuous show that cannot be adequately displayed by the cost per minute. That can also not be displayed by the fundraising goal, but it doesn't need to and everyone will assume that shows might have varying production costs.

To your question about show popularity:
The money raised should not show how popular a show is. Of course popular shows will have an easier time raising money. And It might be they get surplus money more frequently.
I believe for determining the popularity there should be a poll. It could be on the same paltform but it should be separate from spending money, because these are different concerns. (They are connected, but not the same)

To the poll:
It shows people would like to know something to base their decision on. But I want to stress again, I do not want this to be the production cost. Nonetheless people seemed to want the information beforehand.

Also see comments in the pull request.

Thank you for your input on this and how you see it. I really would like to be clear on what I mean with my idea.

@roschaefer
Copy link
Owner

Hey @kirstin if you don't mind, I'll close this. We have a small community at AgileVentures with junior developers now and they assign themselves to Github issues. For that reason, I would like to close issues which we are not going to implement in the next 6 months or so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants