ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

Special User Sections > DC Website Help and Extras

An Idea: Providing some small funding for a yearly (or 6 month) regular coder

<< < (2/6) > >>

guidance on funding site to fund members is as follows:

(1) don't leave direction open.
(2) enroll those who are willing to fight against eternal september.
(3) disperse based on amount collected threshold schedule.
(4) petition funding (newsletters etc) based on date schedule.
(5) disperse only if valids found.

openness can work. cohesion must be owned. recipients are asked only that they win.

Spoilerexplained, this means:

do: (1,2): donationcoder must own donationcoder funds. copyright/left/dontcare is separate from this. policy must be owned; ownership of code and spirit is the member's job in this regard, it is not the same thing as funds. funds must belong to donationcoder to ensure exchange for funds is productive.

do: (3,4,5): funding is best petitioned on a date schedule, collected until it reaches an amount-threshold schedule, and the only dispersed if it finds validity to exchange for. in this way, wealth (actual code and name) is promoted, and funding is guarded against the worst-case hamster wheels.

do not do: strangeness, over-permissiveness, let-the-users-do-whatever, and gofundme-like activity. this is not advised. this does not end well, and leaves a bad taste. (it also leads to people walking in, setting up camp in your house, and taking your house). such thinking is itself a 'hippie-like' method that only works inside of high-cohesion/high-shared-values companies. it has, is, and will always be subverted. (in less polite terms: cucked, parasitic-like exploitation, etc). this is an unfortunate but omnipresent concern, which is necessary for the long-term. however, if efficient enough, and with other members being successful enough (and agreeing to support it), the short-term limited openness can be afforded to a degree. and while many feel it should, it is my experience that only successful owners who have a real non-monetary non-ad/news/publishing stake will truly sense when this 'do-not-do' line is crossed.

essentially, you're looking at funding direction by members to coders (exists already, member directed), funding direction by site to coders (new program, donationcoder directed), and lastly funding direction to site (member directed to house costs). it may look complicated, but it's just accounting. keep it simple. outline a process, draw a flow-chart to clear up what you're doing, and you're good to go. as such, it's just about choosing what level of overhead work/complexity/granularity you want. at the end of the process, funds that go un-awarded for lack of opportunities are best left alone, or sent back to the house costs. and finally, never forget, of course, that might exists first, and exchanging it for funding is just that: an exchange. funding is not source, it is merchant, it is just a tool.

I just want to mention that OxygenicOctavian has made a generous donation towards this fund, and with DC matching it and another pledge from another user, I am happy to say that we have (our first?) $1,000 grant to provide to a coder (or coders).

Now it's just a matter of writing up some small description of how people should apply for it and see if we can't pick one or two recipients.

I am thinking that the model I like best is the idea of providing a no-strings-attached grant to a DC member who has already written and maintains software that is free (for personal use).  The goal is to recognize and encourage their work, and it should possibly focus on student recipients.  The recipient would be under no obligation to do anything with the grant money.

That's another reason why we depend so much on voluntary user donations -- and why we are somewhat persistent in our efforts to get people to at least consider donating (see my article here).

The recipient would be under no obligation to do anything with the grant money.
-mouser (May 19, 2017, 09:46 AM)
--- End quote ---

there is sort of an 'obligation'? i agree it isn't anything as big as 'obligation'. a trust is extended, for the spirit of donationcoder, to then know and manage some donations. it is an acknowledgement to the laissez-faire reality of not knowing what's going to be a good ahead of time, and donationcoder having better position visibility than any given passer-by.

i suppose the difference is really as simple as just not choosing worst-case.

In my opinion there is best intent, based on the recipient's own moral compass.  The selection process should be set up so that it can filter out those that have no intent, and as for the others, if they are members of the community with some ties.  If something happens so that they are not able to complete nor reimburse, then I'd hate for this to be about money- that kind of thing has destroyed relationships and communities throughout the passage of time.

Here's the thing -- trying to choose who to give such an award to is impossible to do in a way that will make everyone happy, and it's impossible to do in a way that recognizes everyone's contributions properly.  I find it agonizing to try to choose who is more deserving of another in these kinds of cases. It's impossible to do "right".

Our only choices are to not do this at all, or do it and accept that there is going to be a huge amount of arbitrary randomness to who is recognized, and accept the idea that if someone doesn't get chosen they shouldn't take it personally and just try for it again next year.

The only solution is to accept the imperfect and arbitrary nature of choosing who to award and not treating it like we are really going to be able to say that person A "deserves" it more than person B.

I think this is going to be more of a case of picking a random recipient among a group of "qualified" coders who enter.


[0] Message Index

[#] Next page

[*] Previous page

Go to full version