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

[mouser]

I was thinking it might be nice to try to organize people on DC who might be willing to commit to spending a few dollars each year (or every 6 months) to help fund a coder.

Obviously we cannot provide real money the way big companies do, but maybe if we work together we could raise enough for a $1,000/year fund, and then pick one different freeware/opensource coder per year to give the money to in order to help them be able to devote more of their time to coding and learning.

It's a small amount of "grant/award money" but just being selected for it might also be somewhat useful to students who are looking for accomplishments to put on a resume, etc...

I'm thinking there would be no obligations from the recipient -- but it's also possible that the award would go towards a particular proposed project and we would want the recipient to post occasional brief public progress updates on the project.  I guess it would depend on the basis for which we would select recipients, which I have no idea.

Just an idea.. Thoughts?

[barney]

mouser, that strikes me as a fine idea  . 

[nitrix-ud]

nice idea mouser

[IainB]

It seems an interesting idea. Lots of questions come to mind.
For example:

• Is "Thoughts?" the right question to ask? Depends, I suppose, on what one hopes to get in response.
• I don't know whether it would be a good or a bad idea, but, if implemented, then wouldn't it potentially be somewhat of a change to the ethos of DC.com?
• And if it is/would be changing it, then what might be the implications of that?
• Does there need to be such a change, and if so, then why/why not?
• If such a change were made, then what could be the potential effect on the existing structure and/or "business model" of DC.com?
• What might be the perception of the external community, and would it matter?
• What might be the specific objectives and outcomes of this? What costs, risks, dependencies and constraints might be involved?
• ...etc.

I'm sure we could think of more questions.

I personally wouldn't attempt to offer any suggestions or answers to such questions at this point, but I would suggest that maybe this would be an opportune time to conduct a PMI (one of De Bono's thinking tools) - a systematic analysis of the Plus, Minus, and Interesting points about the idea, from several different perspectives.

Collectively, we could surely contribute constructively towards such an analysis if we were organised to do so in the role of a kind of distributed "Brains Trust" for that exercise. There is such a diverse collection of minds in the DC forum that we could well run the risk of a synergistic outcome if we were organised by The Project Manager to do that.   

I would recommend the use of a computer tool to collect the PMIs from the audience.
An affinity diagramming tool may be the ideal. The MS Labs Sticky Sorter comes to mind. That can interchange data between the SS tool and a spreadsheet - which could be handy.
But this is getting ahead of ourselves and is just some of my thoughts.

Falling back on my professional training, I'd usually recommend a structured approach. In that case, the first thing required would be to draft up a TOR - Terms of Reference - for a small project to research and implement such an idea, or one similar. The TOR would need to be approved by a Sponsor and/or a Steering Committee before any work started. If one did not do that, then the thing might skitter all over the place like a blob of mercury.

[mouser]

The problem with me and these ideas is that they end up in the discussion stage so long that the idea just withers away and dies of neglect, usually after an unnecessarily complex discussion of a million different remote possibilities and complicated options.

Let's try keeping things simple and pulling the trigger on a test run of this idea, as follows:

I'll send out a newsletter in early May, announcing that we give away a grant of $1,000 of funding for the 6 month period of July-December.
Folks will have until June 1 to submit a short (less than 1 page) proposal by email, describing a coding project they plan to work on during that time.
Meanwhile I will collect pledges from anyone who wants to help fund the grant.
Ideally we would raise enough pledges to be able to do this every 6 months.

As for choosing who to award the grant money to and how, I'm sure we will learn how to do a better job, but for now we can simply have a discussion among those who are pledging the money and decide how to split it up.
There is no reason we have to have only a single "winner", and no reason we shouldn't allow teams, etc.  But I think having the money go to a single recipient will help make it feel like it's actually meaningful for them.
But we could award non-monetarily-significant official "grant" status for others if that might have some value for them in terms of getting recognition, publicity, credit in school, etc.
I suggest that we simply ask recipients to pledge to write a short monthly project report and an end-of-grant summary, all can be in the form of simple short blog posts.
 

[OxygenicOctavian]

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.

Spoiler

explained, 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.

[mouser]

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).

[OxygenicOctavian]

The recipient would be under no obligation to do anything with the grant money.

-mouser (May 19, 2017, 09:46 AM)

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.

[wraith808]

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.

[mouser]

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.

[Ath]

Well, had I known this 5 months ago... I'm now entering the final rounds of a (volunteer) coding project, that has to be completed before July 1st, that could have met the criteria for this 'challenge'
Though we didn't discuss ownership of the code (should be mine as I wrote it all, in my own time) and the question of open-sourcing it, or not. That question is planned for the next meeting. But it's not one of the criteria here, AFAICS.
Maybe next project

[mouser]

The main thing I worry about with something like this is.. How to justify giving away $500-$1000 to someone randomly when there are long term members of the forum who regularly code like mad in the coding snacks area of the forum for example, making the place a better place for all of us..

Perhaps a better thing would be to give the money to coding snack coders?

[Ath]

Perhaps a better thing would be to give the money to coding snack coders?

-mouser (May 20, 2017, 08:52 AM)

That would probably work better if the number of snack requests was higher than it is currently. And the size of a snack usually involves only a couple of hours work (and sometimes even less). And most snacks are handled by 2 or 3 persons... But it would be an extra motivator for picking up a request, I guess. Now to find a way of increasing the volume

It seems you end up with the same dilemma's as the last time you brought up this subject

[mouser]

It seems you end up with the same dilemma's as the last time you brought up this subject

Well my/our specialty is making things complicated and overthinking things..

[mouser]

So yet another alternative would be that at the end of each year, in addition to celebrating the NANY events, we try to "recognize" the contributions of coders to the forum over the last year -- so a summary of contributed coding snacks and releases etc., and as part of that recognition divide up $1,000 in some way to those who have contributed in various ways over the last year.

The upside would be that it would be a less arbitrary way of thanking those who have contributed their efforts and code and shared it on the forum, in a more representative way and without ignoring the contributions to the community here.

The downside would be that it would be a much more "diluted" thing and would therefore not have as big an impact as one person receiving one big lump sum "award".

[OxygenicOctavian]

specialty is making things complicated and overthinking

-mouser (May 20, 2017, 10:28 AM)

haha.

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).

Spoiler

yes, 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).

Spoiler

this 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)

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)

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.

[wraith808]

with bonus points for quality apps

-app103 (July 11, 2017, 04:09 PM)

How do you judge this?  And who judges it?

[mouser]

Everyone will offer their comments on a public thread listing the new apps, and then a select group of long time dc members and those who have contributed to the fund will conduct some kind of vote.  I expect it will be largely just a matter how how many apps were released by each person.. with minor tweaking for giant apps counting as two units, or small apps counting for half a unit.  I expect it will be very non-controversial, but if there is some disagreement we can write a little script to do the voting and weighting. 

As I said, let's start with the simplest approach and if it turns out something more complicated is needed we'll code a solution

[wraith808]

Everyone will offer their comments on a public thread listing the new apps, and then a select group of long time dc members and those who have contributed to the fund will conduct some kind of vote.  I expect it will be largely just a matter how how many apps were released by each person.. with minor tweaking for giant apps counting as two units, or small apps counting for half a unit.  I expect it will be very non-controversial, but if there is some disagreement we can write a little script to do the voting and weighting. 

As I said, let's start with the simplest approach and if it turns out something more complicated is needed we'll code a solution

-mouser (July 11, 2017, 05:28 PM)

Sounds good 

[Ath]

let's start with the simplest approach and if it turns out something more complicated is needed we'll code a solution

-mouser (July 11, 2017, 05:28 PM)

+1 

[mouser]

It's time to make this happen..  I need some help.. Could I beg someone try to make a list of all new software (updates and new) released by dc people in 2017?  I think with that list we can divide some funding among those coders.