Re: [Snowdrift-discuss] Let's talk about the mechanism

[David Thomas]

I'm with Aaron here.  Addressing over-funded projects should not be
even a medium-term thing (unless it looks likely we'll have some
sooner).

On Fri, Dec 23, 2016 at 5:48 AM, Stephen Michel
 wrote:
> Good catch; I just read the local time and went with that but they are
> indeed inconsistent. I'll be online shortly and around for most of them, I
> think.
>
> On December 23, 2016 7:14:50 AM EST, Jason Harrer 
> wrote:
>>>
>>>
>>> Would anyone be able to meet tomorrow morning at 10am PT, noon ET,
>>> 13:00 UTC?
>>
>>
>> Confused on time:  10am PT = 1pm ET = 6pm (18:00) UTC.  Depending on which
>> exact time you're talking about, I may or may not be able to join the
>> meeting.
>>
>> If it's 10am PT, I have a meeting conflict for my day job.
>>
>> If it's noon ET, I would have an hour to talk before the aforementioned
>> meeting.
>>
>> If it's 13:00 UTC, I'm free in 45 minutes.
>>
>> Let me know.  Thanks.
>>
>>>
>>>
>>> --
>>> William Hale
>>> aka Salt
>>>
>>> Community Director
>>> Snowdrift.coop
>>>
>>> "Crowdmatching for Public Goods"
>>> ___
>>> Discuss mailing list
>>> Discuss@lists.snowdrift.coop
>>> https://lists.snowdrift.coop/mailman/listinfo/discuss
>>
>>
>
> --
> Sent from my phone; please excuse my brevity.
> Email policy: http://smichel.me/email
>
> ___
> Discuss mailing list
> Discuss@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/discuss
>
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss

Re: [Snowdrift-discuss] Let's talk about the mechanism

[Stephen Michel]

Good catch; I just read the local time and went with that but they are indeed 
inconsistent. I'll be online shortly and around for most of them, I think. 

On December 23, 2016 7:14:50 AM EST, Jason Harrer  
wrote:
>>
>>
>> Would anyone be able to meet tomorrow morning at 10am PT, noon ET,
>> 13:00 UTC?
>>
>
>Confused on time:  10am PT = 1pm ET = 6pm (18:00) UTC.  Depending on
>which
>exact time you're talking about, I may or may not be able to join the
>meeting.
>
>If it's 10am PT, I have a meeting conflict for my day job.
>
>If it's noon ET, I would have an hour to talk before the aforementioned
>meeting.
>
>If it's 13:00 UTC, I'm free in 45 minutes.
>
>Let me know.  Thanks.
>
>
>>
>> --
>> William Hale
>> aka Salt
>>
>> Community Director
>> Snowdrift.coop
>>
>> "Crowdmatching for Public Goods"
>> ___
>> Discuss mailing list
>> Discuss@lists.snowdrift.coop
>> https://lists.snowdrift.coop/mailman/listinfo/discuss
>>

-- 
Sent from my phone; please excuse my brevity.
Email policy: http://smichel.me/email___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss

Re: [Snowdrift-discuss] Let's talk about the mechanism

[Jason Harrer]

>
>
> Would anyone be able to meet tomorrow morning at 10am PT, noon ET,
> 13:00 UTC?
>

Confused on time:  10am PT = 1pm ET = 6pm (18:00) UTC.  Depending on which
exact time you're talking about, I may or may not be able to join the
meeting.

If it's 10am PT, I have a meeting conflict for my day job.

If it's noon ET, I would have an hour to talk before the aforementioned
meeting.

If it's 13:00 UTC, I'm free in 45 minutes.

Let me know.  Thanks.


>
> --
> William Hale
> aka Salt
>
> Community Director
> Snowdrift.coop
>
> "Crowdmatching for Public Goods"
> ___
> Discuss mailing list
> Discuss@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/discuss
>
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss

Re: [Snowdrift-discuss] Let's talk about the mechanism

[Aaron Wolf]

On 12/22/2016 06:50 PM, Jason Harrer wrote:
> Not sure where my comments would fit into the conversation, so please
> forgive me in advance for responding on top instead of within the thread.
> 
> I think the topic of next steps is a great idea.  I think the topic of
> modifying the current logic is rather premature.  We don't have enough
> data to determine the efficacy of what we already have.  I strongly
> recommend we wait for the mechanism to start working before we determine
> whether or not it's broken.
> 
> I feel we need to focus more on website functionality instead.  As I see
> it, we have several great possible next steps that ultimately need to
> get done (though not sure what order we want to tackle them):
> 
> 1) User enhancement:  We have the bare minimum user capabilities (not
> even a user's name anymore).  We could take the time to flesh out the
> user's settings, make administration pages to allow a user/admin to
> reset passwords (get away from manually making manual changes to the db).
> 
> 2) Project pages:  Obviously, this needs to happen before we can add
> more projects, and we would need to consider whether or not we would
> transition the Snowdrift.coop project into the same framework we set up
> for all other projects.  Plenty of work to be done in this area:  The
> page itself, sign up pages, admin pages (because, again, better
> ultimately to avoid manual changes to the db)...
> 
> 3) Data reporting:  We've discussed in the past setting up charting
> using SVG or some other format easily integratable (not sure if that's a
> word, but...) within HTML/CSS.  We'd need to determine what data we want
> to present, set up functions that calculate the data and the front end
> to display it.
> 
> 4) Subsite integration:  We already have SSO code for Discourse, but not
> sure if/which other subsites will need to be integrated into
> Snowdrift.coop for use by normal users.  If there are others, we'll want
> to try to figure out SSO for them as well.  We may also want to figure
> out some site integration testing for the various subsites to ensure we
> don't accidentally break something down the road.
> 
> Any thoughts on this?
> 
> - Jason (JazzyEagle)
> 
> 

All great thoughts, Jason! I hope that we get the SSO and the rest of
Discourse set up soon, because this is a perfect case for it. I want to
move your post to a new thread etc. but that's not how mailing-lists work…

I think *discussing* this is good here and then Discourse when ready.
Doing the actual organizing about which things are priority and should
have our attention should still be at
https://tree.taiga.io/project/snowdrift

Personally, I'm taking the limited focus I have and working on writing
things that relate to intro video, wiki content, stuff in Discourse,
etc. and wanting to prioritize getting to a point where we can look at
the site and feel good enough to make an announcement about the alpha
launch.




signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss

Re: [Snowdrift-discuss] Let's talk about the mechanism

[Jason Harrer]

Not sure where my comments would fit into the conversation, so please
forgive me in advance for responding on top instead of within the thread.

I think the topic of next steps is a great idea.  I think the topic of
modifying the current logic is rather premature.  We don't have enough data
to determine the efficacy of what we already have.  I strongly recommend we
wait for the mechanism to start working before we determine whether or not
it's broken.

I feel we need to focus more on website functionality instead.  As I see
it, we have several great possible next steps that ultimately need to get
done (though not sure what order we want to tackle them):

1) User enhancement:  We have the bare minimum user capabilities (not even
a user's name anymore).  We could take the time to flesh out the user's
settings, make administration pages to allow a user/admin to reset
passwords (get away from manually making manual changes to the db).

2) Project pages:  Obviously, this needs to happen before we can add more
projects, and we would need to consider whether or not we would transition
the Snowdrift.coop project into the same framework we set up for all other
projects.  Plenty of work to be done in this area:  The page itself, sign
up pages, admin pages (because, again, better ultimately to avoid manual
changes to the db)...

3) Data reporting:  We've discussed in the past setting up charting using
SVG or some other format easily integratable (not sure if that's a word,
but...) within HTML/CSS.  We'd need to determine what data we want to
present, set up functions that calculate the data and the front end to
display it.

4) Subsite integration:  We already have SSO code for Discourse, but not
sure if/which other subsites will need to be integrated into Snowdrift.coop
for use by normal users.  If there are others, we'll want to try to figure
out SSO for them as well.  We may also want to figure out some site
integration testing for the various subsites to ensure we don't
accidentally break something down the road.

Any thoughts on this?

- Jason (JazzyEagle)



On Dec 22, 2016 19:11, "Stephen Michel"  wrote:

On Thu, Dec 22, 2016 at 7:43 PM, William Hale  wrote:

On Thu, 22 Dec 2016 17:10:23 -0500 Stephen Michel 
wrote:

This is the spiritual successor to Bryan's "Snowdrift.coop's immediate
goals" (quoted below), but is a bit broader in scope, so I'm starting a new
thread.

I know that Aaron mentioned this in a subthread, but I wanted to
re-iterate. This seems like a separate topic of discussion.


Maybe "spiritual successor" was too strong. I agree it's a separate
discussion, but think Bryan's email was important context.

Specifically, noting that he was talking about setting goals. The major
proposed change is to incorporate more formal goal setting -- which is less
of a major change if we're already doing it.

On Thu, 22 Dec 2016 17:10:23 -0500 Stephen Michel 
wrote:

The reality is, each project's constraints will be different. I informally
propose the following approach to calculate things: 1. Define an income
goal. 2. Define an patron count goal. 3. Calculate $pp ($ needed per
patron), income/patrons 4. Calculate match level, $pp / patrons

This is a decent model to consider and it would be nice to have some graphs
in a financial report for Snowdrift.coop


One thing I don't feel I made sufficiently clear: This model (the numbers)
is something that each *project* can do. In that sense, it's unrelated to
points A and B, which are things that we would do with the *platform.*

It's somewhat easy to confuse these two since right now we are the only
project on the platform.

Thoughts?

Regarding the topic at hand, I am on the side of "Don't Make Me Think".
Adding any additional pledge settings is contrary to this.


Which pledge settings are we talking about? In either case there's a single
pledge/unpledge button.

We have agreed that some method is needed for patrons who want to give more.


Ack, I'm now regretting my decision to bring this up, since as you've both
mentioned that's really a separate discussion.

Aaron wrote:

I think the appeal of set goals for money and patrons is understandable
but problematic. Projects and patrons are *shitty* at determining these
things. The majority of patrons will be *wrong* about their predictions
about how they'll feel about their budget in the long-term even. The
point of the budget is to just give them needed control and assurance.


Also from IRC: Projects would be able to change those goals. Patrons get
notifications for each change. If a change would increase the limit
per-patron, patrons must confirm that they wish to remain patrons (which
encourages projects to adjust their goals by shooting for more patrons at a
lower crowdmatch rate, rather than getting each patron to pay more.

We want people to say "I'm in" for the vision and stay involved and see
where things 

Re: [Snowdrift-discuss] Let's talk about the mechanism

[Aaron Wolf]

To summarize some IRC thoughts I wrote:

I think the appeal of set goals for money and patrons is understandable
but problematic. Projects and patrons are *shitty* at determining these
things. The majority of patrons will be *wrong* about their predictions
about how they'll feel about their budget in the long-term even. The
point of the budget is to just give them needed control and assurance.

We want people to say "I'm in" for the vision and stay involved and see
where things go, staying in as they like the progress and providing
feedback and dropping if unhappy.

The setting of hard goals creates anchor points, pass/fail judgments,
and lots more issues. If these approaches were fundamentally bad, we
wouldn't see them so commonly. But if they really worked well, we
wouldn't see so many problems related to such things.

The deepest, broadest version of Snowdrift.coop could probably spend $1
million per month on all worthwhile things. The reality is that we will
probably *operate* for a long while with less funds than we even ought
to have for reliable comfortable basic operations. Drawing lines between
those is going to be based on much less information than we'd like to
have. I think it should stick to only casual "we could probably do X
with Y funds" as a vague statement of intentions rather than a decision
with ramifications about how much people donate to us.

That's my feeling right now about these things.



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss

Re: [Snowdrift-discuss] Let's talk about the mechanism

[Aaron Wolf]

On 12/22/2016 02:14 PM, Stephen Michel wrote:



> Although we need to think beyond MVP, we still need to limit our scope.
> I am including the following because it strengthens the argument for
> this system.
> 
> Please ONLY discuss it insofar as it relates to "should we adopt the
> system?". Do NOT discuss specific details of how exactly we'd implement
> such a system; they are OUT OF SCOPE right now.
> 
> This system also offers the most elegant solution I have seen so far to
> the question, "What if someone wants to support a project beyond
> standard patronage?"
> 
> Projects can offer different pledge levels. It's still wordy to explain
> in abstract, but it's easy with an example:
> 
> A regular patron pledges, "I will donate $0.001 per patron (including
> super-patrons), capped at $2/mo."
> A super-patron pledges, "I will donate the same as a regular patron, AND
> I will donate an additional $0.01 per super-patron, capped at $20/mo."
> An alternate phrasing for is, "I will match regular patrons at their
> level, and match super-patrons at a higher level."
> 
> This gives projects a way to customize their income needs (eg, you could
> make a super-duper-patron, meant for grants/foundations, where it's $100
> per super-duper-patron, max $2k), while also keeping the number of
> different levels manageable (that was the main problem with the
> *original* concept of shares, imo -- there's so many different levels
> you have to think about).
> 
> 

Although some ways connected, I'd rather we discuss this issue of
different patronage levels on a different thread than the one about
designing patronage around set project funding goals.




signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss

Re: [Snowdrift-discuss] Let's talk about the mechanism

[Stephen Michel]

On Thu, Dec 22, 2016 at 5:10 PM, Stephen Michel 
 wrote:
On Mon, Dec 5, 2016 at 1:41 PM, Bryan Richter  
wrote:

Now that the reboot of the site is operational, I think it's time to
start at the top and work our way down to our next immediate goals.

Well, I'll skip ahead a bit, because I think it's obvious:

I propose we set a target for Snowdrift's monthly crowdmatch income, 
and

hit it as soon as possible. This seems like the best way to guarantee
the successful project we all want to see.

I think the other viable alternative is to set a goal of a certain 
crowd
size. That's the more idealistic goal. But we need realistic goals, 
not

idealistic ones. :) By making income the goal, it frees us to tweak
donation settings to be successful with possibly fewer patrons.

So what should the amount be?

$1000, because it's a nice round number?

$3500, to adequately cover current expenses?

$6000, so Snowdrift can continue paying me to be lead developer? (I
can't keep going at my current rate.)



We should also set a timeframe for our goal, so we have some way of
measuring the passage of time and progress.

We need to feel out what sort of goal is truly realistic. I have no
idea. Aaron and Salt, how many people do you think will sign up to
support us in the next — say — three months? Everyone, what sort 
of

crowdmatch tweaks are the most likely to be successful?

Right now we're growing at about one patron a day (up to twelve
now!) What does success look like? A one-time step to 2000 patrons? A
smooth curve?

To me, these are the most important questions Snowdrift.coop is 
facing

right now.

-Bryan

P.S. This says nothing about the priorities and projects of the 
separate
teams within our organization. I had actually wanted to talk about 
that,

but I'll leave it for another email.


This is the spiritual successor to Bryan's "Snowdrift.coop's 
immediate goals" (quoted below), but is a bit broader in scope, so 
I'm starting a new thread.


The questions he outlines in that thread apply to more than us. 
They're the most important questions that *any* project that wishes 
to use the site will be asking. We should have answers.


Here's some other, related questions. They're not MVP, but we're 
close to MVP and need to start thinking beyond it.


What happens if we don't have the user base to support our project's 
income needs?
What happens if we have too many patrons, and people can't afford to 
pledge?
How do we assuage people's fear (realistic or not) that a project 
will explode and eat up their budget?


The reality is, each project's constraints will be different. I 
informally propose the following approach to calculate things:


1. Define an income goal.
2. Define an patron count goal.
3. Calculate $pp ($ needed per patron), income/patrons
4. Calculate match level, $pp / patrons

Then we follow these rules:

A. All patrons have their pledges capped at $pp. Much like how we 
currently have a hard limit on the snowdrift project. If a project 
has enough patrons that the pledge would go over $pp, it remains at 
$pp instead (so the extra patrons act as a buffer, in case some 
patrons drop out).
B. We "remove" (ie, never implement) the concept of a patron-set 
pledge limit, and also of deactivated pledges. They're no longer 
needed because when you pledge to the project, you're guaranteed that 
your pledge will not exceed a certain value. We should still show the 
total value on your dashboard (the sum of the limits of all the 
projects you pledge to).


So for us, that looks like:

i. My vote is for $3500, to cover current expenses.
ii. I'm going to arbitrarily pick 1871 patrons.
iii. So we need $1.87 $pp.
iv. Match level is $0.001 -- our current level.

A big advantage of this system is that it corresponds really well to 
an idea of, "I'll do my part, but only if everybody else does 
theirs", which I've found to be really effective way of explaining 
the mechanism. It's like Wikipedia's "If everyone reading this gave 
$3..." message. And then you go to the site, and see the pledge level 
at (for example) 1/100 of a cent per patron, capped at $3. So if 30k+ 
patrons each pledge, the level hits $3 and Wikipedia gets its funding.


Thoughts?

~Stephen


Although we need to think beyond MVP, we still need to limit our scope. 
I am including the following because it strengthens the argument for 
this system.


Please ONLY discuss it insofar as it relates to "should we adopt the 
system?". Do NOT discuss specific details of how exactly we'd implement 
such a system; they are OUT OF SCOPE right now.


This system also offers the most elegant solution I have seen so far to 
the question, "What if someone wants to support a project beyond 
standard patronage?"


Projects can offer different pledge levels. It's still wordy to explain 
in abstract, but it's easy with an example:


A regular patron pledges, "I will donate $0.001 per patron (including 
super-patrons),