Special User Sections > DC Website Help and Extras

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

<< < (4/6) > >>

OxygenicOctavian:
specialty is making things complicated and overthinking
-mouser (May 20, 2017, 10:28 AM)
--- End quote ---
haha. :D

not worried. give it a try. a possible model:

(A) establishing the definite "should not" actions (always step one at each iteration).
(B) past this, there are no definite "should" actions (no one knows that to the same degree of certainty).
Spoileryes, there will be some members who have sipulations on preferred "shoulds." but some what separately, i prefer the "rule-in" to be completely at one assigned discretion. that is, first place an executor faith, and then let that entrusted choose the recipient alone ("you lead this time," etc). this keeps the distraction of "how" separate, preventing any inadvertent division of the ability to succeed. yes, the choice could fail, but that's a post-hoc-ergo-propter-hoc worry best discarded. no one knows ahead of time. the best knowledge of "how" comes from one person owning that decision. committees/democratic/vote in the action side do not work.

the choice of "shoulds" is left to the executor to do the work and account for it (C).
(C) in iteration finality, post a simple log of approximate in/out (testify and log for future).
Spoilerthis establishes the record. it reaffirms the entrusted in at the very least (1) said what it was going to do, (2) did what it said, (3) and now demonstrates that it did it. this is "the log" of action. that final "report" itself is the "member return of faith" today, leaving the rest open for the recipient (the "return of faith tomorrow"). tomorrow could be an arbitrarily long ways away, not worried. that onus is on the executor, they own their act, etc.

even if things fail spectacularly (which i don't think they will the first time thru), always document and post. this will at least restore some faith, even if failure is outright. the executor can be changed around at next iteration, or the whole process revised, etc. the general idea should always be to avoid known worse-case failures, separate and limit the amount of overhead on the admin side, and prevent hobbling on the chance-of-success side. this also keeps perceptions of obligation on the program, leaving the recipient more "hard expectation free."
...
accept that there is going to be a huge amount of arbitrary randomness
-mouser (May 19, 2017, 03:38 PM)
--- End quote ---
accepted. faith is extended, to donationcoder, to make the call. let ambition guide you.

mouser:
I've been ruminating on this idea and I think that I've come to a conclusion that there is an easier, smarter, fairer, and overall better way to do this, and that is to do the following:

At the end of each year (or every 6 months) , we will round up the money dedicated to this purpose (aiming for $1k per year; possibly getting some from our fundraiser or other pledges), and then divide it between the coders who have created Coding Snacks and NANY programs in the previous year (I am exempting myself from being eligible).

There may be some minor weighting of contributions in different ways, but the objective will simply be to divide up the funds each year based on the efforts put in my coders in creating software on the dc forum.

I think this approach is the cleanest, simplest, fairest system and it has the real benefit of showing thanks from DC funders to those who are making this site better.

wraith808:
I've been ruminating on this idea and I think that I've come to a conclusion that there is an easier, smarter, fairer, and overall better way to do this, and that is to do the following:

At the end of each year (or every 6 months) , we will round up the money dedicated to this purpose (aiming for $1k per year; possibly getting some from our fundraiser or other pledges), and then divide it between the coders who have created Coding Snacks and NANY programs in the previous year (I am exempting myself from being eligible).

There may be some minor weighting of contributions in different ways, but the objective will simply be to divide up the funds each year based on the efforts put in my coders in creating software on the dc forum.

I think this approach is the cleanest, simplest, fairest system and it has the real benefit of showing thanks from DC funders to those who are making this site better.
-mouser (July 08, 2017, 12:12 PM)
--- End quote ---

Agreed.  If someone wants to fund a project, there are better ways in my opinion.  But putting this into a pot and rewarding someone- that seems like a good idea.

I'd also add this suggestion- as a part of NANY, have a nomination process, where people nominate things from the prior year, and prior year's NANY, and then vote on them, and give the project that wins a special reward.

app103:
How about at the end of the year, you enter every DC coder that has done some work on coding snacks, NANY, etc into a drawing, with each app they have released earning 1 entry, with bonus points for quality apps (to discourage anyone from joining and releasing a ton of crap "just to get another entry" type apps)? Those that have done a lot of work would have a better chance of winning than someone that only did a single lesser quality app.

It could be a good use for your prize optimizer.

Or you could just hand the money over to Skwire.  ;)

mouser:
We could run a giveaway if there were special items to give away, but otherwise I think maybe we keep it simple by making a public list of all new software released on DC in the last year, let people make any comments they want (an informal version of what wraith says above), and then have the dc mods and those funding the money consider those comments make a group decision on how to divide up that years funding.

Navigation

[0] Message Index

[#] Next page

[*] Previous page