avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Sunday October 2, 2022, 11:47 pm
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - OxygenicOctavian [ switch to compact view ]

Pages: [1]
specialty is making things complicated and overthinking
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).
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).
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
accepted. faith is extended, to donationcoder, to make the call. let ambition guide you.

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

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.

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.

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.

UrlSnooper / Re: Urlsnooper is great
« on: March 01, 2008, 01:12 PM »'s a great program.

affirmative; money donated.

Pages: [1]