[Snowdrift-discuss] new Snowdrift.coop forum, email lists closing

2018-12-18 Thread Aaron Wolf
Hi! This email list has been inactive for a long time, but that’s not
because work stopped on Snowdrift.coop — it’s because we’ve moved to our
new community forum at https://community.snowdrift.coop

Please join us there! It’s integrated with your main Snowdrift.coop
account, so no need to separately register.

Read more about the new forum at this blog post:
https://blog.snowdrift.coop/new-forum

In other news, the main site has a new intro video! Also, initial
crowdmatching for us (as the first test project) is live.

We still have a lot to do to get fully operating. Your help and
encouragement makes a difference, so to stay engaged please come say
"hi" on the forum as a next step. We look forward to further discussion
with you there!

This discuss email list will be closing soon. Archives will remain at
https://www.mail-archive.com/discuss@lists.snowdrift.coop

Cheers,

--
Aaron Wolf
co-founder, Snowdrift.coop



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


Re: [Snowdrift-discuss] Set monthly donation limit?

2017-12-26 Thread Aaron Wolf
On 12/26/2017 02:00 PM, James Cook wrote:
> Hello,
> 
> Great to see some functionality on the site!
> 
> In the Budget section of my dashboard, I see the message: "You will
> never be charged more than your budget limit of $10 per month." Is
> there a way to change the monthly limit?
> 
> James

Hi James,

The full spec certainly calls for that to be adjustable (otherwise, it's
more of a zero-sum game if you can't increase your budget when things
grow and you feel it's worth it to stay in the crowd!), but we don't
have that feature finished yet.

As an all-volunteer team, there are always things people can do if they
want to help us accelerate to having that and other things in place.

Cheers,
Aaron



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


[Snowdrift-discuss] Updated Snowdrift.coop Code of Conduct

2017-12-25 Thread Aaron Wolf
Hi everyone,

I updated the Code of Conduct last week:

https://wiki.snowdrift.coop/community/conduct

Key changes:

* made several items positively framed instead of prohibitions

E.g. "Keep criticism constructive" instead of "No unconstructive criticism"

* added new item about keeping meta comments out of band

Specifically: "Keep meta comments outside of focused topics"

This is the most substantial change, but it's actually just an expansion
and clarification of items that were already present about not publicly
responding to objectionable posts and otherwise avoiding off-topic posts
etc.

(A short explanation of this item is in the CoC itself, see link above)

* added no-sexual-comments

This was actually not covered adequately by any previous entry even
though we had posts about unwarranted attention to other posters.

* changed order and improved some minor wordings

Unfortunately, our Discourse forum doesn't have quite as optimal a
flagging system as we had in our old integrated discussion boards, but
it's close, and we'll work on updating it as best we can to effectively
integrate the CoC with the flagging.

For elsewhere, like IRC, mailing lists, GitLab issues etc. we don't have
a formal, strict way to flag or enforce the CoC, but please do what you
can there anyway. Whenever a concern comes up, we will address it
privately and/or outside the original context so that it does not get in
the way of the initial discussion.

Feel free to reply with any questions or feedback.

Along with solidifying other governance, we will in the future have a
more formal process for updates like this.

Cheers

-- 
Aaron Wolf
co-founder, Snowdrift.coop



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


[Snowdrift-discuss] Defining terminology for Snowdrift.coop

2017-11-22 Thread Aaron Wolf
Greetings everyone,

I opened some issues on the wiki repo:
https://git.snowdrift.coop/sd/wiki/issues

about settling on terminology for various things, especially around the
main crowdmatching system.

#4 there https://git.snowdrift.coop/sd/wiki/issues/4 is a brainstormed
list of all the terminology we need and some other issues have been
opened for specific items on that list.

Please feel free to weigh in with thoughts or additional brainstormed
items either on the issue discussion or here on this thread on the
mailing list.

Thanks!

-- 
Aaron Wolf
co-founder, Snowdrift.coop



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


Re: [Snowdrift-discuss] Non-Profit Question

2017-11-13 Thread Aaron Wolf
On 11/13/2017 12:31 AM, jake wrote:
> Clearly, Snowdrift.coop is non-profit.
> 
> But must all projects funded on Snowdrift be non-profit?
> 

No, but none of the project requirements are set in stone since we still
have to roll out that whole structure.

The plan is *not* to require that all projects be legal non-profits but
that all the work funded from Snowdrift.coop go toward the direct
development of public goods. That means not getting funded from
Snowdrift.coop and just then giving the money to investors or keeping it
as profit without putting it toward new work.

> If so, the developers may be paid as an expense to the non-profit
> organization. But at what point does this become a profitable business
> for the developers?

This seems to be a misunderstanding of the whole nature of non-profit
entities. Nearly all non-profits have paid employees, and some are paid
decently. What makes a non-profit is that there are no investors who own
stock and get returns on their investment. There can still be any number
of paid employees paid to do work.

> Is it simply that the developers are not allowed to make purchasing
> decisions for the organization, such as to pay themselves?

That issue has more to do with who makes decisions. That is not an issue
for non-profits per se (or Snowdrift.coop projects per se), but there
are legal regulations around decision-making when it comes to tax-exempt
organizations (like 501(c)(3) in the U.S.). I'm not a lawyer so can't go
into details there.

> 
> The big question: is it ethical to essentially start a business using
> Snowdrift? There are business models where a company commercializes
> open-source software. Take CodeWeavers and Red Hat, Inc., for example.
> 

Ethical is a philosophical question. I think there are at least ethical
questions about the whole concept of profit. I certainly it's unethical
to put profit *over* the public good in any situation.

As for Snowdrift.coop, we're not focusing on *starting* businesses but
on funding the creative work that produces or improves public goods.

Codeweavers makes a commercial product based on Wine. We would support
Wine itself (and it's fine for Codeweavers to share in the benefits of
the improvements to Wine).

Red Hat provides hardware and support while using free software like
Gnome. We would support Gnome and other free software that Red Hat uses.
Red Hat (or other new companies) are perfectly welcome to do business
providing hardware and support services around the free software we support.

> 
> Cheers,
> Jake
> 

Hope that answers your questions. Feel free to ask more.

Cheers,
Aaron



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


[Snowdrift-discuss] General project-management suggestions

2017-08-21 Thread Aaron Wolf
Hi everyone,

I was reading this:

https://blog.taiga.io/definition-of-ready-definition-of-done-the-difference.html

I think that is a very nice structure to have this clear checklist of
questions. We could use that as a foundation to have our own very
similar checklist so we can better make sense of our tasks/projects and
how to work on them together.

I'd like to hear any thoughts or get into discussing how we can apply
this to our workflow.

-- 
Aaron Wolf
co-founder, Snowdrift.coop



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


[Snowdrift-discuss] Meeting notes from today

2017-07-14 Thread Aaron Wolf
Here's the link:
https://wiki.snowdrift.coop/resources/meetings/2017/2017-07-14-meeting

(those with next-steps assigned to you: do whatever you need to track
them and get to them when you can!)

Anyone interested is welcome to join us same time (21:00 UTC / 2PM
Pacific) next Friday.

Work progresses, and there's always ways to help out if you're
interested. We're happy to hear any questions / encouragement /
critiques / suggestions…

In harmony,
Aaron

-- 
Aaron Wolf
co-founder, Snowdrift.coop



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


Re: [Snowdrift-discuss] PCI compliance

2017-07-10 Thread Aaron Wolf
On 07/10/2017 01:53 PM, fr33domlover wrote:
> Hello everyone,
> 
> 
> I found a nice website with human readable info about PCI compliance:
> 
> 
> 
> I'm bringing this up especially because right now Snowdrift is using Stripe's
> proprietary JS, which will surely raise eyebrows sooner or later, and
> regardless of that, I suppose we need this PCI thing. Anyone has thoughts 
> about
> it?
> 
> My thoughts are:
> 
> - What does PCI compliance affect? If we don't have it, who will it bother 
> etc.?

In short: there's no value in considering going without it, it's
required. It's a severe legal liability to ignore such things.

> - How does the FSF handle it? They take donations without a single bit of
>   proprietary JS. And they are in the US too (except they are legally an
>   official non-profit organization). Maybe we can check how they do it?
> 

I think they do it by actually getting credit card info and then using a
card-processing service. This means they have overhead and liability in
handling those things. Also, this only works because they process
single, large charges.

In our case, we would be an illegal money transmitter if we held funds.
We can't otherwise charge tons of times for multiple small charges per
patron for each and every project they support.

Stripe allows us to do single charges per patron and single payouts per
project, combining it all.

There's a free-software replacement for Stripe's JS that pushes all the
compliance issues onto us, but we really don't want that risk and overhead.

The real long-term solution is what CrowdSupply does: They accept the
financial details on their front-end using only free software and then
have the server send the information to Stripe using Stripe's API and
without *ever* storing the info. This still means touching the financial
details, so it comes with security overhead that we haven't been able to
handle at this time with our limited resources. But this is the solution.

(Incidentally, I wrote an issue or something about eventually following
Crowd Supply's example, but I'm not sure where that lives now… does
anyone know how to find it. I searched Taiga and didn't find it. Maybe
it's there somewhere though, or…?)

> --fr33
> 
> 



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


Re: [Snowdrift-discuss] Funding opprtunity?

2017-02-10 Thread Aaron Wolf
On 02/10/2017 04:18 PM, Michael Siepmann wrote:
> On 02/10/2017 02:58 PM, Tufts wrote:
> 
>> On Fri, Feb 10, 2017 at 3:48 PM, Bryan Richter 
>> wrote:
>>> On Fri, Feb 10, 2017 at 12:40:52PM +0100, Robert Martinez (mray) wrote:
>>>
>>> On 09.02.2017 19:04, Bryan Richter wrote: > On Thu, Feb 09, 2017
>>> at 05:40:24PM +0100, Robert Martinez (mray) > wrote: >> The FSFE
>>> ML just put my attention to a funding project of the >> german
>>> government: >> >> https://prototypefund.de/en/ >> >> It looks
>>> like they pay 30.000€ over a 6-month period, given that >> you
>>> meet some requirements. Imho Snowdrift.coop has a chance. > >
>>> Looking at the first round's winners >
>>> (https://prototypefund.de/en/our-first-round-of-funding-goes-to/), >
>>> I'd say I completely agree. > > But it says, "Self-employed and
>>> independent developers who live in > Germany can apply for
>>> funding." Do we have anybody that meets that > criterion? > > Oh,
>>> I see on the application itself it asks, "Are you applying as an
>>> > individual or as a team." Still, I would expect the whole team
>>> might > need to live in Germany. mray, how much extra room do you
>>> have in > your house? ;) > > Or perhaps we could recruit some
>>> people. I am certain there are > Haskellers in Germany who would
>>> want to help out. As Salt proposed I asked about the necessity of
>>> being an entierly german GbR the answer was: The only thing that
>>> really matters is that the ones receiving the money have their
>>> residence in Germany. 
>>>
>>> Then it sounds like you should apply! Is there anything the team
>>> should do to support the application? Do we have any good milestones
>>> that could be used as a "goal" to help sell the application? (Since
>>> having a concrete goal would make the application more enticing.)
>>
>> Milestones: https://tree.taiga.io/project/snowdrift/epics
> 
> On the topic of funding sources, has this one already been considered or
> tried?
> 
> https://www.shuttleworthfoundation.org/

Shuttleworth Fellowship is probably the best fit of many options. We've
applied twice over the years and not received the fellowship. We should
still apply again.

We have this list: https://wiki.snowdrift.coop/market-research/grants

And I have a list of more to consider and add to that, and would be
happy to see this German thing and other appropriate stuff added. Anyone
interested in helping us decide and pursue such resources is welcome to
do that. It's hard to judge priority because applying and not getting
them does take away from our direct work.




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


Re: [Snowdrift-discuss] FOSDEM 2017 - flyer?

2017-01-31 Thread Aaron Wolf
On 01/31/2017 01:50 PM, Asbjørn Sloth Tønnesen wrote:
> Hi,
> 
> Being one of the 30 patrons so far, I think it's stalling a bit too much at 
> the moment.
> 
> So I have made a A4 flyer suitable to hang on the many pin boards along the 
> hall way
> track at FOSDEM this weekend.
> 
> The audience at FOSDEM is 5000+ free and open source developers and project 
> maintainers.
> 
> http://asbjorn.it/pub/misc/noidx/snowdrift/fosdem2017.pdf
> http://asbjorn.it/pub/misc/noidx/snowdrift/fosdem2017.svg
> 
> If blessed I will print them on thursday around noon UTC.
> 
> 

Thanks so much for being proactive! Last year, we had someone from the
team at FOSDEM, but that didn't happen this year although there are
supporters.

We really need to at least summarize the situation in a public fashion:

Our lead developer left his dedicated position (and our immediate
funding ran out), although he's staying on as a volunteer. He got the
first real pledging functioning, but too much of the setup and the
operations of the pledging is left in a non-final state. We've been
scrambling (all as volunteers) to get to a state we feel will have a
positive result from lots of attention.

Those who already support us will be excited to see the progress, but
we're not in a good state to give a good first impression.

Our goal is to verify that the actual payout system is operating
correctly and clean up the design so it's acceptable to get good
impression for newcomers.

Anyway, I think the poster does a good job of expressing the in-progress
early-alpha situation. In the debates about whether attention is good
before ready or whatever, I'm not sure what's right. I'm not opposed to
spreading the word with adequate qualifications.

I do find this bit confusing:

n patrons pledges n mUSD / month = n^2 mUSD / month

I understand exactly what it means, but I don't think it's clear enough
to someone seeing the poster.

Typo "too be made" should be "to be made" but I'd change to "will be
adjustable in future" or something like that.

Overall, I appreciate the support and pro-activeness enough to lean
toward giving an "okay" in sharing this etc. even though it's not
perfect. Perfect is the enemy of the good.

I would like to see what others think. As long as it's totally clear
that this is NOT the big alpha launch announcement, it's better to get
volunteers and interest than not. We definitely need CiviCRM used better
and keep organized that way around the contacts.

P.S. I saw you made a separate donation as a pre-launch sponsor! Thank
you!! It's in my list to follow up and to add you to the /sponsors page
if you'd like to be listed etc.

-Aaron




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

2016-12-22 Thread 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

2016-12-22 Thread 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

2016-12-22 Thread 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] Development status

2016-10-19 Thread Aaron Wolf
> Please stop the talking, the postponements, stop telling
> people what you want to do and just do it ffs. Start with
> something simple, do a prototype, get feedback, stop wasting
> time. If you don't, your project will be a huge waste and
> you'll be dead as soon as some other person who cares about
> freedom decides to start a similar donation platform. And
> let me tell you, when that happens people won't give a
> glorious damn of your revolutionary snowdrift idea, they
> will just care of a free platform that works (and if the
> "snowdrift idea" turns out to be any useful, the cost of
> adding that for them would be minimal compared to your cost
> of fixing a broken platform).

One quick note: the above has been my concern from DAY ONE. I wanted to
launch before Patreon. We would have had first-mover advantage in this
whole space. There's all sorts of reasons our platform and system
*could* have become the main thing, and it's *awful* that didn't work out.

But the reality is that we would have launched with a much more complex
algorithm which would have been problematic in various ways. We now have
a ton of things cleared up that we didn't have in place originally.

We can take some solace in the ideas of later-mover success being possible.

In the end, I care less that Snowdrift.coop succeeds than that society
actually solves funding for public goods. Patreon is a positive step in
that it frees some projects from relying on ads or proprietary
restrictions. It isn't everything it should be.

There's some tragedy to the situation here, but each step, including
right now, the best choice is to go forward toward launch.

Again: we NEED and WELCOME anyone to help keep us on track. Making all
the right choices to find the shortest path to success is *not* easy,
it's easy to get sidetracked. We may not know which path is the shortest
or best, and perspective is always welcome.

I'm still hopeful that this will succeed and make a real impact. But
there's so many challenges yet to face.



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


Re: [Snowdrift-discuss] Development status

2016-10-19 Thread Aaron Wolf
On 10/19/2016 11:41 AM, Rosario Suarez wrote:
> Do you guys have any serious, practical, defined, concrete, real plan to 
> bring Snowdrift up to a working state anytime soon? Because I've been 
> following this project for years, and all I see is talk and talk and nothing 
> ever happens. You've already spent probably more than 10 grands as well (I 
> even donated to your campaign!), and all we have now is just a mailing list, 
> and a white-page website with a bunch of comics on it. And now I've found 
> this comment https://freepo.st/post/c59i7bf0ha#comment-r5loimcuf9 "we're 
> struggling to get launched still", that needless to say made me very angry. 
> Does it mean that you won't be ready for another 5 years? Is there any hope 
> you'll have something by the end of this year? Because let's be honest, 
> you're not working on Snowdrift as you'd work on a project that you want to 
> succeed; you're working on it as a spare time hobby.
> I'm mad because I really think Snowdrift is a cool project, and *you* are 
> cool people who care about free software. I want to use and support Snowdrift 
> just because there isn't anybody else out there that cares about freedom of 
> software and art works. And this is clear from your page 
> https://snowdrift.coop/p/snowdrift/w/en/othercrowdfunding hundreds of 
> websites, all of them suck because they either don't take freedom into 
> consideration, or have ridiculous fees (they are not non-profits), or both. 
> But goddamn, you guys don't know how to manage a project! Instead of hiring 
> developers, you should hire a project manager who doesn't take bad decisions 
> and who knows how to get this project going. You could already get hundreds 
> of free developers if only you chose a language other than Haskell.
> Besides, if you don't know how to get this "snowdrift" idea going, just quit 
> this bullshit and start with something simpler, for example classic, 
> traditional donations and work your way to the "snowdrift" on a later time. 
> Let's be real guys, sooner or later you will eventually have to implement 
> other donation types (other than your "snowdrift" idea), just because people 
> donate in many different ways (for example one time, or maybe once a year on 
> christmas). So, if you can't get snowdrift going, just start with something 
> simpler and build on that. You should realize that I don't care about your 
> project because the "Snowdrift" is any revolutionary idea; I just care about 
> it because it's free, because I know the people working on it understand what 
> freedom is, and because there is nobody else doing the same thing. And I feel 
> most people feel the same.
> 
> Please stop the talking, the postponements, stop telling people what you want 
> to do and just do it ffs. Start with something simple, do a prototype, get 
> feedback, stop wasting time. If you don't, your project will be a huge waste 
> and you'll be dead as soon as some other person who cares about freedom 
> decides to start a similar donation platform. And let me tell you, when that 
> happens people won't give a glorious damn of your revolutionary snowdrift 
> idea, they will just care of a free platform that works (and if the 
> "snowdrift idea" turns out to be any useful, the cost of adding that for them 
> would be minimal compared to your cost of fixing a broken platform).
> 
> Peace \o/

Thank you for the note, Rosario! You *might* be surprised at how rarely
we get this sort of message. I mean, *I* think that Snowdrift.coop is
extremely important and have taken it very seriously. It's been quite
frustrating to talk with so many people who both recognize the potential
*and* have the skills, resources, connections, to help us make it a
reality and then have the vast majority never make the leap into truly
helping it get there. Most don't even take the time to send us a note
like this or otherwise.

Now, having said that, a far greater portion of those folks would be up
for helping if we had the whole plan so clearly structured and easy to
approach that everyone knew just what to do and had just the right
guidance to get into participating. Still, people come and go. And the
work needed to figure out how to make a truly welcoming, effective,
productive community is itself massive.

I've been wanting to get around to writing a post about the challenges
we've been facing, the struggles, mistakes, learning experiences, and
most of all: expressing to everyone why this project is actually as or
more ambitious than almost any out there. All along, part of me knew
this was extremely challenging, but I'd hesitate to have pushed it
forward if it seemed hopeless. I got by trying to believe the most
optimistic folks.

Now, a summary:

Snowdrift.coop was started by two people: one with perspective on the
mission, values, scope, and community-building; and one with technical
expertise. It turns out that the technical expert was too optimistic in
what was doable by himself or 

Re: [Snowdrift-discuss] How to manage fees for first real-money operations

2016-10-07 Thread Aaron Wolf
On 10/06/2016 09:44 PM, Bryan Richter wrote:
> On Thu, Oct 06, 2016 at 06:46:10PM -0700, Aaron Wolf wrote:
>>
>> First, the premise: As a financial system trying to get people focused
>> on how public goods actually work and are actually funded, we don't
>> want fees hidden and absorbed. We want people to see and experience
>> the costs of the tools they use.
> 
> I agree with this. Sharing the responsibility for fees is good.
> Besides, it would be impractical to do anything else when there are many
> projects.
> 
>> Is there a reason we can't just add the fee amount to the total
>> that we charge everyone? That should be baked into our mechanism
>> calculations. The charge is: base * patrons + fee.
> 
> Here's the problem: Stripe calculates the fee themselves. If we try to
> charge the fee upfront, we effectively increase the fee by another 3%.
> (math below).
> 
> I see four possibilities right now.
> 
> 1. Charge up front to cover the fees.
> 
> This results in the increased fee percentage just discussed.
> 
> 2. Swallow the fees.
> 
>There is only one project right now: Snowdrift. All donations are
>going to Snowdrift. It is actually financially feasible to just
>accept the losses on the Snowdrift side as long as all remaining
>money is actually going to us.
> 
>But we don't like this option, since it sets poor expectations. It
>also means that the crowdmatch amount is not equal to what the
>project receives.
> 
> 3. Set up a second, connected Snowdrift account using Stripe Connect.
> 
> With a second account, we can "charge through the platform"[1] and
> add an application fee that is equal to the processing fee. This is
> by far the cleanest mathematically. Conversely, it is the hairiest
> legal option.
> 
> We will probably have to do this eventually, assuming it's even
> possible. But it's a big barrier to "shut up and take my money".
> 
> [1]: 
> https://stripe.com/docs/connect/payments-fees#charging-through-the-platform
> 
> 4. Charge the donation amount, but only register a 'crowdmatch' equal
>to the net transaction balance.
> 
>The goal is that the patron is still paying exactly the minimum
>fee. They are simply matching a "virtual" crowd that is slightly
>smaller than the "actual" crowd.
> 
>The problem with this is that it's WAAYY confusing, and prone to
>weird rounding errors converting backwards and forwards. I was
>excited about this method until I realized how crazy it would be.
> 
> MY SUGGESTION:
> 
> As much as we want to set expectations, I think the most sensible course
> for the Futurama milestone is (2). It is very easy to describe what it
> is doing, as well as what our eventual goals are.
> 
> I am VERY WEAKLY against (1) just for the sake of principles, as well
> because I think it's slightly harder to explain than (2). That's
> subjective, and I'm open to consensus overruling.
> 
> I am against (3) because it adds trickiness and delay when we just want
> to have some freakin' cash flow.
> 
> I am against (4) because it's a nightmare.
> 
> -
> 
>> Side-note: if we made it possible to use Dwolla instead or other
>> no-fee options, this would be a non-issue for those cases.
> 
> This will happen many months from now, at best. We shouldn't think about
> it until we have more than half a dozen projects being supported.
> 
> 
>  MATH LOL 
> 
> Here's the math for my claim that we would increase the fee by 3% if
> we charge the fee upfront.
> 
> Let's call the amount we charge the patron up front "epsilon". If we
> want Snowdrift's net balance to be `original + crowdmatch`, the equation
> we want is
> 
> (crowdmatch + epsilon) - fee = crowdmatch
> 
> or just
> 
> epsilon = fee  (1)
> 
> But since we would charge `crowdmatch + epsilon`, the fee is:
> 
> fee = 0.029 (crowdmatch + epsilon) + 30  (2)
> 
> Combining (1) and (2),
> 
> epsilon = 0.029 (crowdmatch + epsilon) + 30
> --> epsilon = 0.029 crowdmatch + 0.029 epsilon + 30
> --> 0.971 epsilon = 0.029 crowdmatch + 30
> 
> Now the right hand side is equal to Stripe's original fee calculation,
> `0.029 crowdmatch + 30`.
> 
> 0.971 epsilon = original fee
> --> epsilon = 1.030 original fee
> 
> QED.
> 
> 

If I understand right, you're just pointing out that the fee we would
need to charge increases by 3% **of the fee**, not doubling the 3% fee
to becoming 6%. I see no problem charging an

[Snowdrift-discuss] How to manage fees for first real-money operations

2016-10-06 Thread Aaron Wolf
So, I understand that in the long-term there may be issues with how to
pass on fees. I'm not sure about those details, so this is about how to
do it initially.

First, the premise: As a financial system trying to get people focused
on how public goods actually work and are actually funded, we don't want
fees hidden and absorbed. We want people to see and experience the costs
of the tools they use.

So, the idea is that we want people to know that 100% of a pledge value
goes to a project even though they will also have to pay the processing
fee when using Stripe.

Side-note: if we made it possible to use Dwolla instead or other no-fee
options, this would be a non-issue for those cases.

Ok, so, for our initial operations, is there a reason we can't just add
the fee amount to the total that we charge everyone? That should be
baked into our mechanism calculations. The charge is: base * patrons + fee.

Technically, I suspect Stripe would claim that all of that (including
the fee) is going to the Snowdrift.coop account directly from the donor,
but then in reality, Stripe will take the fee out for themselves before
actually giving us the money. But we can then express to the donor the
true amount we get, what Stripe is taking, and express that the fee does
not reduce the money received per the crowdmatching calculation.

Thoughts?

-- 
Aaron Wolf
co-founder, Snowdrift.coop



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


Re: [Snowdrift-discuss] New Slogan: "Crowdmatching for public goods", terminology clarification.

2016-09-20 Thread Aaron Wolf
WHOOPS, I was too TIRED. I mistyped! I obviously meant:

"CrowdMATCHING for public goods" not "crowdfunding"

Sorry for the confusion there. The first few paragraphs should be
changed to "crowdmatching" where I carelessly wrote "crowdfunding"

Sorry!



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


[Snowdrift-discuss] New Slogan: "Crowdfunding for public goods", terminology clarification.

2016-09-20 Thread Aaron Wolf
I'm not sure about capitalization, happy to get thoughts there.

Otherwise, as the lead for Communications in our Holacracy governance, I
hereby declare that our new slogan is:

"Crowdfunding for public goods"

Furthermore, I want to reiterate (and will update the terminology wiki
page accordingly) that *the* term we shall use to describe our mechanism
is "crowdfunding" and *the* term we shall use to describe the types of
works we support is "public goods".

Although I appreciate Stephen's feedback, the decision for the slogan is
not based solely in anyone's intuition about the isolated effect of the
slogan itself. The decision is based on the need for the slogan to fit a
consistent communication strategy throughout the whole site.

Although "free/libre/open" and FLO will remain prominent, that will be
used to refer to the subset of public goods that we are focusing on for
the foreseeable future. Public goods include lighthouses and arguably
some public infrastructure (e.g. roads that have zero realistic
possibility of getting overloaded with traffic), and we are not focusing
on those things. It makes little sense to describe a lighthouse as FLO.
A lighthouse is a different sort of public good. We will, in principle,
consider expanding to cover all public goods, but we're focused on FLO
public goods now and potentially forever.

It's actually arguable that a non-free CC-ND licensed work is a "public
good" and we will communicate that we see that as entering a grey, fuzzy
area where the viewing and sharing of the video is indeed public good
status but the work's lack of status as a cultural artifact to be used
and remixed freely makes it not fully public good in all regards.

I see FLO as an important term but with its own baggage.

Anyway, I'm not going to take more time here justifying the decision.
I'm not closed to further discussion, but we need to progress to launch,
not debate every detail. I also need to be able to be decisive and
effective in my role.

Again, the communication policy for everyone going forward: "public
goods" describes the type of economic works that face the snowdrift
dilemma and similar, and we shall have a strategy of *spreading* that
way of talking about it and *owning* this message.

With a successful strategy, people will learn to talk about "public
goods" and how they face the "snowdrift dilemma" and how
Snowdrift.coop's "crowdmatching" solves the problems. We want to get
people talking and thinking this way. This shall be our communication
strategy, and our name and slogan serve as the initial prompt consistent
with this.

We shall not try to vaguely come up with alternate terms for ideas that
already have clear definitions.

Of course this policy can be updated or changed as needed, but this is
the decision now. Let's please get to work launching the site and
implementing this communications strategy wherever applicable.

Cheers,
Aaron


On 09/20/2016 11:31 AM, Stephen Michel wrote:
> On Tue, Sep 20, 2016 at 12:21 PM, Michael Siepmann
> <m...@techdesignpsych.com> wrote:
>> On 09/20/2016 08:40 AM, Aaron Wolf wrote:
>>> On 09/20/2016 01:04 AM, mray wrote:
>>>> On 20.09.2016 02:25, David Thomas wrote:
>>>>> What about dropping "fund"?  "Crowdmatching for public goods"
>>>> What about dropping "for"?
>>>>
>>>> "Crowdmatching for public goods"
>>>> "Crowdmatching public goods"
>>>>
>>>> You could say we ultimately crowdmatch for everybody, not for public
>>>> goods. Omitting "for" also makes Crowdfunding more of verb than a noun,
>>>> which is a good thing; more active and less static.
>>>>
>>>> Michael rightly notes that "fund" clarifies what we mean without
>>>> depending on new words. Mike rightly notes that it implies some sort of
>>>> funding. I think when we introduce a new word we also need to let it do
>>>> some lifting, otherwise we shouldn't introduce it. Redundancy in a
>>>> slogan is bad. Short is good.
>>>>
>>> I find "crowdmatching" as a noun is a little easier to parse when it has
>>> no context (i.e. isn't in a clear sentence). Also "crowdmatching for
>>> public goods" works if you parse it as a verb or a noun, whereas
>>> "crowdmatching public goods" makes anyone who starts parsing as a noun
>>> do the mental work of shifting it to a verb.
>>>
>>> The main reason I'm hesitant about (but not totally opposed to)
>>> "crowdmatching public goods" is that the matching isn't matching of
>>> public goods to one another, but it could read that way.

Re: [Snowdrift-discuss] Clearer slogan?

2016-09-20 Thread Aaron Wolf
On 09/20/2016 01:04 AM, mray wrote:
> On 20.09.2016 02:25, David Thomas wrote:
>> What about dropping "fund"?  "Crowdmatching for public goods"
> 
> What about dropping "for"?
> 
> "Crowdmatching for public goods"
> "Crowdmatching public goods"
> 
> You could say we ultimately crowdmatch for everybody, not for public
> goods. Omitting "for" also makes Crowdfunding more of verb than a noun,
> which is a good thing; more active and less static.
> 
> Michael rightly notes that "fund" clarifies what we mean without
> depending on new words. Mike rightly notes that it implies some sort of
> funding. I think when we introduce a new word we also need to let it do
> some lifting, otherwise we shouldn't introduce it. Redundancy in a
> slogan is bad. Short is good.
> 

I find "crowdmatching" as a noun is a little easier to parse when it has
no context (i.e. isn't in a clear sentence). Also "crowdmatching for
public goods" works if you parse it as a verb or a noun, whereas
"crowdmatching public goods" makes anyone who starts parsing as a noun
do the mental work of shifting it to a verb.

The main reason I'm hesitant about (but not totally opposed to)
"crowdmatching public goods" is that the matching isn't matching of
public goods to one another, but it could read that way. It's patrons
who match each other.

If we were to do without a preposition, we could use:

"public goods crowdmatching"

To me, that's a nice effect but feels more dense and jargony. Of all the
options proposed "Crowdmatching for public goods" feels like the least
mental work to read and parse. The preposition helps me chunk it into
two clauses. It's a noun (or maybe a verb) with a preposition clause.
That's easier to process than parsing one jargony, heavy verb clause.




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


Re: [Snowdrift-discuss] Clearer slogan?

2016-09-19 Thread Aaron Wolf
On 09/19/2016 08:41 PM, Mike Linksvayer wrote:
>> So, I'd accept "crowdmatching for public goods"
> 
> I really like "crowdmatching for public goods". I suspect that if I read that 
> without context, I'd take funding as implied, and be surprised if the thing 
> with that slogan didn't involve funding.
> 
>> although I *slightly*
>> worry that wording could be inferred to mean that you could have
>> crowdmatching for other things. The message I wish to send is "[funding]
>> public goods through crowdmatching" where [funding] could be other
>> assistance if we expanded.
> 
> I don't think any amount of words will prevent others from using the term 
> crowdmatching for exclusive goods. I wish nobody would use the term 
> crowdfunding to describe anything other than funding public goods. "Match" is 
> good because it conveys very simply how the mechanism is different, not 
> because it is a yet-unspoiled term. "Crowdmatching for public goods" very 
> nicely communicates what Snowdrift.coop will soon do, I hope.
> 
> Mike
> 

Okay, Mike convinced me. I think we should embrace "Crowdmatching for
public goods"




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


Re: [Snowdrift-discuss] Clearer slogan?

2016-09-19 Thread Aaron Wolf
On 09/19/2016 04:37 PM, Michael Siepmann wrote:
> On 09/19/2016 01:57 PM, Aaron Wolf wrote:
>> "Free the Commons" is a nice, short, relevant slogan. It's a call-to-action.
>>
>> But freeing in what sense? What commons? What are "the commons"? And
>> technically, "commons" are rivalrous shared resources, not actually the
>> public goods which are technically what we're working with.
>>
>> I just was chatting with Robert and ended up saying "I don't think we'll
>> come up with much better, but the idea we want to express is something
>> like 'Crowdmatching to fund public goods'"
>>
>> Well, what do you think?
>>
>> ** Crowdmatching to fund public goods **
>>
>> It's longer and wordier than "free the commons" but is more accurate. It
>> gets right away into our use of 'crowdmatching' and clarifies that it's
>> for fundraising, and uses "public goods" correctly. I'd think a reader
>> would immediately say "what's crowdmatching?" and "what are public
>> goods?" at which point those are indeed *the* two questions we want
>> people to ask and that we want to answer concisely in order to introduce
>> Snowdrift.coop.
> 
> I strongly agree.  I while ago I suggested "Catalyzing creation of
> public goods" among other ideas for a new tagline.  "Catalyzing
> creation..." was definitely too vague, but the term "crowdmatching"
> didn't occur to me until a few months later.  I think this new
> combination of "crowdmatching", "fund", and "public goods" is excellent
> and should be a big help in quickly giving people a basic understanding
> of what Snowdrift.coop is about.
> 
> 

Some alternatives of the same content:

Crowdmatching to fund public goods
Crowdmatch funding of public goods
Crowdmatched funding of public goods
Crowdmatch funding for public goods
Crowdmatched funding for public goods
Crowdmatching funding of public goods
Crowdmatching funding for public goods
Crowdmatching funds for public goods
Public goods funding through crowdmatching
Funding public goods through crowdmatching
Crowdmatching funds public goods

Incidentally, the only shorter one than my initial suggestion is a
stranger grammar to parse because it's a complete sentence instead of
just a verb clause or a noun clause. I think a clause is better than a
sentence. So, it looks like the first suggestion may be best anyway.






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


[Snowdrift-discuss] Clearer slogan?

2016-09-19 Thread Aaron Wolf
"Free the Commons" is a nice, short, relevant slogan. It's a call-to-action.

But freeing in what sense? What commons? What are "the commons"? And
technically, "commons" are rivalrous shared resources, not actually the
public goods which are technically what we're working with.

I just was chatting with Robert and ended up saying "I don't think we'll
come up with much better, but the idea we want to express is something
like 'Crowdmatching to fund public goods'"

Well, what do you think?

** Crowdmatching to fund public goods **

It's longer and wordier than "free the commons" but is more accurate. It
gets right away into our use of 'crowdmatching' and clarifies that it's
for fundraising, and uses "public goods" correctly. I'd think a reader
would immediately say "what's crowdmatching?" and "what are public
goods?" at which point those are indeed *the* two questions we want
people to ask and that we want to answer concisely in order to introduce
Snowdrift.coop.


-- 
Aaron Wolf
co-founder, Snowdrift.coop



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


Re: [Snowdrift-discuss] Using Stripe.js will break LibreJS

2016-09-03 Thread Aaron Wolf
Update: I checked with Crowd Supply what they do…

They say they simply have a form that doesn't use any JS, they process
the form data server-side and send to stripe via Stripe's API, and they
never store any payment data to disk so avoid any extra compliance burden.

This approach would work with NoScript even! I don't know what the
issues would be, and I could imagine that doing this delays our
"take-my-money" immediate functional launch, but I'll leave that
determination to Bryan. If this would work, it seems the full solution
with tons of advantages…



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


Re: [Snowdrift-discuss] migrating users

2016-08-12 Thread Aaron Wolf
On 08/12/2016 07:31 AM, Bryan Richter wrote:
> Since persona is shutting down, we have to migrate everyone to an
> email/passphrase authentication system.
> 
> I did some analysis of the user table to see what that would require.
> I found a few different categories of user, which may need different
> treatments. I broke it down into six different groups[1].
> 
> ##
> ## THE GROUPS
> ##
> 
> #
> # Group 1: Verified email and modern hash[2]
> #
> (Count: 218)
> 
> "Modern hash" means a stored passphrase we can use in the new system.
> See footnote for more detail.
> 
> #
> # Group 2: Unverified email and modern hash
> #
> (Count: 146)
> 
> Four of them have ident=email, which might mean they joined with
> Persona, and created a password later. (?)
> 

With Persona start and passphrase added, email would have gotten
verified if the pass was added after our verify-the-Persona-emails
action. I think the main reason for ident=email but unverified email is
someone simply manually making their ident be their email and including
email in the sign-up too, so they match, and never verifying (i.e. all
without Persona).


> #
> # Group 3: Verified email, but no modern hash
> #
> (Count: 425)
> 
> 420 of these are people with no hash at all. They must have signed up
> with Persona.
> 
> The remaining five have an old-style salt/hash combo. They're
> basically in the same bucket as people with no hash at all.
> 
> #
> # Group 4: Unverified email, no modern hash, and ident!=email
> #
> (Count: 4)
> 
> Three of these are probably people who signed up with Persona, but
> then changed their email and didn't verify it.
> 
> One is just somebody with an old-style salt/hash combo.
> 
> #
> # Group 5: Unverified email, no modern hash, ident=email
> #
> (Count: 11)
> 
> All of these people must have signed up with Persona and can be
> automatically verified. Then they will become members of group 3.
> 

When we verified all no-hash, no-email accounts and matched their ident
to email, perhaps we left out people who had manually already matching
their email to their ident? Otherwise I don't know why we missed these,
but I agree that any account with no hash at all must have been
Persona-based.

> #
> # Group 6: No email
> #
> (Count: 254)
> 
> These poor folks need to add and verify an email address to be part of
> the system.
> 

Based on some cases of comments or profiles or other knowledge, we may
know who a few of these users are, but most will be impenetrable.

> ##
> ## ANALYSIS
> ##
> 
> I think the first thing to remember is that almost all of these users
> are diehard fans of the project. I won't feel bad about accidentally
> sending one extra email to them, and I don't feel especially worried
> about accidentally verifying a spammer[3] or identity theft victim.
> 
> So.
> 
> The biggest group is #3 (verified but no passphrase), with almost half
> our users. I suggest we send a one-time email to them after we go live
> with master, telling them to use ForgotPassphrase to initialize a
> passphrase.
> 

Makes sense to me, just make the message specific to their case so it's
clear.

> The next biggest group is #6 (no email). That's bad. Things aren't
> hopeless, though. Half of them have an email address as an identifier!
> We can perhaps send them an email as well, telling them that now would
> be a good time to formally add an email address to their account. We
> can also just read through the list to see if we recognize any names.
> 

Yup

> Next up is group #1 (verified and modern). Great. No action required.
> 

Okay, interjection: if idents must be emails now, we still want to
maintain distinct ident vs email columns in the db? Maybe that's the
easiest and cleanest… Long-term, we'd like to support having multiple
emails available (like one for ident and one for notifications or
something). But if we were starting fresh, would we have the two columns
and make them match or just use ident *as* email?

> Group #2 is a tricky one (unverified but modern). We *could* just
> assume they're all good caring folks, and automatically verify their
> emails. I suggest instead that we send an email now asking them to
> verify their email using the existing system, so that they can become
> members of group #1. The rest would be out of luck.
> 

I agree about sending email to verify.

> I can make everyone in group #5 (unverified, ident=email, no hash)
> become a member of group #3 by automatically verifying their email.
> This is safe to do since they *must* have signed up with Persona.
> 
> For group #4 (unverified, ident!=email, no hash), I think we should
> reach out to them individually. There's just four of them.
> 
> ##
> ## PROPOSED ACTION
> ##
> 
> There's a really really easy solution to this migration question: blow
> away the entire user table and start over from scratch. Everyone
> creates a new account. (Plan HECK)
> 
> There's also the super fine-grained deeply-considered maximally
> optimal solution, which I've 

Re: [Snowdrift-discuss] How the limit works

2016-08-09 Thread Aaron Wolf
On 08/09/2016 06:31 AM, Stephen Michel wrote:
> 
> 
> On August 9, 2016 8:59:16 AM EDT, Bryan Richter <br...@snowdrift.coop> wrote:
>> On Wed, Aug 03, 2016 at 03:55:42PM -0700, Aaron Wolf wrote:
>>> On 08/03/2016 03:48 PM, Stephen Michel wrote:
>>>> On Wed, Aug 3, 2016 at 6:46 PM, Aaron Wolf wrote:
>>>>> On 08/03/2016 03:29 PM, Stephen Michel wrote:
>>>>>>  What happens if someone wants to set their limit lower than the
>>>>>>  minimum credit card charge?
>>>>>>
>>>>> We would not allow such a low limit. The range of allowable
>>>>> limits will start high enough minimum to be sensible.
>>>>
>>>> What is the current thinking on the minimum value? I've seen $2
>>>> and $5 thrown around.
>>>>
>>>
>>> There's no more clarity than that. I guess I'll go ahead and propose
>>> we start with $5 as minimum budget.
>>
>> Related question:
>>
>> What is the minimum sensible charge?
>>
>> Stripe's front page advertises a fee of 2.9% + 30¢.
>>
>> CrowdmatchFeeTotal  Fee/Total   Fee/Crowdmatch
>> ---
>> $0.10 30¢   $0.40  75.18%  302.90%
>>  0.20 31 0.51  60.46   152.90
>>  0.30 31 0.61  50.71   102.90
>>  0.50 31 0.81  38.6162.90
>>  0.80 32 1.12  28.7740.40
>>  1.30 34 1.64  20.6225.98
>>  2.00 36 2.36  15.1817.90
>>  2.10 36 2.46  14.6717.19
>>  3.40 40 3.80  10.4911.72
>>  5.50 46 5.96   7.71 8.35
>>
>> Based on that table, I think $2.00 is the minimum sensible charge.
>>
>> I suggest we specify it as a maximum fee percentage, however, to help
>> adapt to future fee differences. That being the case, I propose we
>> choose 15% as the maximum fee percentage (plus or minus some tenths of
>> a percent).
> 
> A % fee max, rounded to the nearest pretty dollar amount, seems like the way 
> to go to me. 15% / $2 seems reasonable to me.
> 

I agree that 15% fee is the maximum fee, seems sensible enough, and that
makes it processor-neutral. I don't agree with Stephen's idea of
rounding to nearest dollar, that's far too low resolution. I think just
rounding to nearest cent is fine.



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


Re: [Snowdrift-discuss] How the limit works

2016-08-03 Thread Aaron Wolf
On 08/03/2016 03:48 PM, Stephen Michel wrote:
> On Wed, Aug 3, 2016 at 6:46 PM, Aaron Wolf <aa...@snowdrift.coop> wrote:
>> On 08/03/2016 03:29 PM, Stephen Michel wrote:
>>>  Clean slate because context is getting absurd and this is important
>>>  regardless of rollover mechanism.
>>>
>>>  What happens if someone wants to set their limit lower than the minimum
>>>  credit card charge?
>>>
>>
>> We would not allow such a low limit. The range of allowable limits will
>> start high enough minimum to be sensible.
> 
> What is the current thinking on the minimum value? I've seen $2 and $5
> thrown around.
> 

There's no more clarity than that. I guess I'll go ahead and propose we
start with $5 as minimum budget.




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


Re: [Snowdrift-discuss] How the limit works

2016-08-03 Thread Aaron Wolf
On 08/03/2016 04:56 AM, mray wrote:
> On 03.08.2016 12:48, Aaron Wolf wrote:
>> On 08/03/2016 01:27 AM, mray wrote:
>>>
>>>
>>> By definition the carry over is lower than the limit where fees make
>>> sense - I expect this to be low.
>>> For this low amount of money to trigger an unfortunate un-matching the
>>> total would have to be full to the brim already. This will hardly
>>> happen, and IF it happens it is only an indicator of a bad situation
>>> that will soon get an auto-un-match anyway. There is not much to gain.
>>>
>>
>> I was going to make this point myself. I agree, it just happens when
>> we're already approaching the limit, which is already an issue, this
>> just triggers it sooner.
>>
>>> This corner case of a corner case is *NOT* worth breaking the *ONE*
>>> limit the user trusts us with!
>>>
>>
>> I must say, I get *less* sympathetic with your views when they are
>> expressed hyperbolically. Charging 2 months at once instead of in two
>> separate charges does not break the limit or the trust. I actually
>> *agree* with you that the experience is cleaner if we make the limit
>> even harder and have less to explain. When you equate "we have to
>> explain combining two months into one charge" with "we broke the trust",
>> it actually makes me less respectful of your view because I disagree
>> with what you are saying.
>>
>> So, to be clear: when you give exaggerated or even bad justifications
>> for something that might be the correct approach, it makes me more
>> skeptical. So, please, try not to use this sort of hyperbole.
> 
> You're welcome to be skeptical about my opinions. Everything that may
> find flaws in reasoning about the mechanism is a good thing. Don't
> decide on that matter on sympathy please, though.
> 
> But I honestly can't see an exaggeration in my statement.
> 
> We only ask for 2 things:
> 1. what projects to match
> 2. ONE limit where to stop the monthly flow of money
> 
> Given the simplicity of a mechanism like ours I think it is really a
> stretch to give room for interpretation about what "monthly limit" might
> mean. There is no doubt that with a fitting explanation we could make it
> mean anything and charge accordingly and "correctly"!
> But the most straight forward interpretation is:
> 
>  "Just don't spend more than that!"
> 

Right, and I agree that all other versions of the limit are problematic
in requiring explanation such as "we may charge multiple months in one
charge." But describing that as seeming desperate or as violating trust
is not a view I think a all sensible for someone who understands the
system to have. It's just inferior because it requires more explanation
and more potential confusion.

It would just be better discourse between us if you'd say "some people
may see it this way…" or "to play devil's advocate, someone who missed
the explanation may feel some loss of trust…"

Those ways of talking show that you, Robert, someone who understands all
the details, recognizes that there's no desperation or untrustworthiness
and you're just worried about what others may think. It also clarifies
that you are speculating about a possibility (which may not occur). It's
a speculation worth being concerned about.

I'm just saying that describing it that way, as speculation about what
others *might* think, will lead to much better internal discussions than
just asserting exaggerated claims.

> With our background of good intentions and devotion to simplicity and
> clarity I do regard it as a hard break to diverge from those qualities
> and see it as our duty to protect them – especially touching the core
> part that relates to trust between us and the user. Even if we "explain"
> and charge "correctly".
> 
>>
>>> I would want to be able to make a promise to honor the limit *without
>>> any restraints*. We can do that. Not doing it makes us look desperate or
>>> needy. People setting a $10 limit should never find a $11 transaction
>>> fee in their payment processors accounting. No matter what wordplays we
>>> come up on our site to differentiate between "monthly pledge" or
>>> "monthly total".
>>
>> So, in the end, you are right that keeping the limit totally clear means
>> less confusion, less to explain (maybe), and I'm okay with going this
>> way. I think you're simply entirely wrong that it makes us look
>> desperate or needy.
>>
>>>
>>> If we let the user set a limit we need a darn good reason to ignore it
>

Re: [Snowdrift-discuss] How the limit works

2016-08-02 Thread Aaron Wolf
On 08/02/2016 06:48 PM, Stephen Michel wrote:

> I think the cleanest initial way to go is "No more than $limit will be
> added to your outstanding balance each month." That is, carried over
> matches should *not* be counted towards your monthly limit, but fees
> should, in their entirety.
>

Well said. Even though I have some willingness to defer to Robert and
see his view…

Well, let me put it this way: Stephen just stated the best wording of my
own initial view. The idea that in two months, I pay less than 2x my
monthly max is just fine. There's nothing objectionable about "we
combined two months of charges into one charge to avoid excessive fees".
That does not violate the expectations of someone having a monthly
budget limit, it just says that they paid the first month late, charged
at the same time as the second month.

So, I think Stephen's suggestion to count fees but not carry-overs is
indeed the best approach, even though I won't fight that hard against
Robert's "no charge is ever more than 1-month's-max". But in the end, a
month that had *no* charges* followed by a 2-month-worth charge the next
month is, I think, still in-line with patrons' budget expectations.



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


Re: [Snowdrift-discuss] How the limit works

2016-08-02 Thread Aaron Wolf
On 08/02/2016 05:58 PM, James Sheldon wrote:
> When are transaction fees charged?  When you add money or when it is
> assigned to a project?
> 

This is assuming a charge-in-arrears approach where we avoid holding
money which has all sorts of legal challenges once we go beyond our one
project. So, there is no separate adding of money, there's only monthly
charges of the funds that will all go to projects for that month.



> On Tue, Aug 2, 2016 at 5:21 PM, Aaron Wolf <aa...@snowdrift.coop> wrote:
>> On 08/02/2016 05:05 PM, mray wrote:
>>> During the last meeting we discussed details about how the limit works.
>>> I just want to voice my opinion on how the limit should work:
>>>
>>> I strongly believe we should make the limit sacrosanct and not touch it
>>> *never ever*. A decision by the user to set a monthly limit trumps
>>> "hidden costs" always, no matter if we frame the limit as "pledge limit"
>>> or "total limit" or whatever else. If payment fees and carried over
>>> matches would break the limit we need to suppress it as usual: auto
>>> un-match until there is no more problem.
>>>
>>> If the user sets a limit she is free to set it higher if that is what
>>> she wants! Crowdmatching itself already is a mechanism that asks to hand
>>> over control, the remaining limit cannot be subject to be overridden by
>>> even more rules.
>>>
>>>
>>> What are your thoughts on this?
>>>
>>>
>>
>> I was mostly concerned about the idea that a one-time thing (a
>> carry-over) would affect the ongoing thing (the suspension of pledges).
>> Like if my pledges are $9 and I have a one-time $2 carry-over with a $10
>> max, the idea that we *suspend* a pledge just so that we process the
>> carry-over seems awkward and unfortunate. With the one-time carry-over
>> processed, everything can go forward next month as is, if there's no
>> changes.
>>
>> Having said that, and not having a problem with the carry-over going
>> over max for myself as a patron, I think you are right, Robert.
>>
>> I generally oppose "hide the weirdness" in that I want people to see
>> behind the curtains and know what's really going on (which is why I want
>> the fees itemized for the patrons, not hidden in any way). But I accept
>> that this is a case where the absolute hard max charge in any given
>> month is going to just be the most comfortable, respectable experience
>> for patrons.
>>
>> The question becomes: is it more annoying to have pledges suspended over
>> a one-time carry-over or more annoying to get charged a little extra
>> more than the max? I suspect it varies among patrons. I think this is a
>> case where eventually having an *option* to say "allow carry-overs to go
>> beyond my max so as to not suspend pledges" would be something some
>> people would want. That said, I think it's a bad idea to get into this
>> right now.
>>
>> I support going with Robert's view that we include fees and carry-overs
>> in the total when determining suspensions in order to keep everything
>> below the max that is set. I think that's the cleanest initial way to
>> go. (Yes, that is a change from what I expressed in the meeting)
>>
>> Happy to hear others' views.
>>
>>
>>
>> ___
>> Discuss mailing list
>> Discuss@lists.snowdrift.coop
>> https://lists.snowdrift.coop/mailman/listinfo/discuss
>>
> 
> 
> 




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


Re: [Snowdrift-discuss] How the limit works

2016-08-02 Thread Aaron Wolf
On 08/02/2016 05:05 PM, mray wrote:
> During the last meeting we discussed details about how the limit works.
> I just want to voice my opinion on how the limit should work:
> 
> I strongly believe we should make the limit sacrosanct and not touch it
> *never ever*. A decision by the user to set a monthly limit trumps
> "hidden costs" always, no matter if we frame the limit as "pledge limit"
> or "total limit" or whatever else. If payment fees and carried over
> matches would break the limit we need to suppress it as usual: auto
> un-match until there is no more problem.
> 
> If the user sets a limit she is free to set it higher if that is what
> she wants! Crowdmatching itself already is a mechanism that asks to hand
> over control, the remaining limit cannot be subject to be overridden by
> even more rules.
> 
> 
> What are your thoughts on this?
> 
> 

I was mostly concerned about the idea that a one-time thing (a
carry-over) would affect the ongoing thing (the suspension of pledges).
Like if my pledges are $9 and I have a one-time $2 carry-over with a $10
max, the idea that we *suspend* a pledge just so that we process the
carry-over seems awkward and unfortunate. With the one-time carry-over
processed, everything can go forward next month as is, if there's no
changes.

Having said that, and not having a problem with the carry-over going
over max for myself as a patron, I think you are right, Robert.

I generally oppose "hide the weirdness" in that I want people to see
behind the curtains and know what's really going on (which is why I want
the fees itemized for the patrons, not hidden in any way). But I accept
that this is a case where the absolute hard max charge in any given
month is going to just be the most comfortable, respectable experience
for patrons.

The question becomes: is it more annoying to have pledges suspended over
a one-time carry-over or more annoying to get charged a little extra
more than the max? I suspect it varies among patrons. I think this is a
case where eventually having an *option* to say "allow carry-overs to go
beyond my max so as to not suspend pledges" would be something some
people would want. That said, I think it's a bad idea to get into this
right now.

I support going with Robert's view that we include fees and carry-overs
in the total when determining suspensions in order to keep everything
below the max that is set. I think that's the cleanest initial way to
go. (Yes, that is a change from what I expressed in the meeting)

Happy to hear others' views.




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


[Snowdrift-discuss] meeting today 18UTC

2016-08-01 Thread Aaron Wolf
In a few hours, meeting at https://meet.jit.si/snowdrift

18UTC = 11AM Pacific

All welcome

-- 
Aaron Wolf
co-founder, Snowdrift.coop



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


[Snowdrift-discuss] video chat today about Snowdrift progress

2016-07-11 Thread Aaron Wolf
Sorry for last minute notice. Anyone interested is welcome to join us
today 18:00 UTC (That's 11AM Pacific) at https://meet.jit.si/snowdrift

We'll be doing this weekly meeting every Monday going forward.

Cheers

-- 
Aaron Wolf
co-founder, Snowdrift.coop



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


Re: [Snowdrift-discuss] greetings from Finland

2016-06-22 Thread Aaron Wolf
On 06/22/2016 07:15 AM, Bryan Richter wrote:
> Hi all,
> 
> Today was my first real day in Finland, and happily I was able to
> settle in and make some progress on Snowdrift. My internet situation
> is still getting squared away, but it should be good soon. I'm way out
> in the countryside, and I'm looking forward to many distraction-free
> hours over the next two or three months!
> 
> I'm still working on an email/passphrase auth system, after which I'm
> going to make it possible to write individual pages with Markdown
> (instead of Hamlet), and then I'll start mocking up either the
> dashboard or project page. I'm sure other things will come up, of
> course. :P
> 
> It feels like I've been distracted and getting ready for this move for
> a really long time. Have I missed anything? How has progress been on
> other fronts?
> 

You didn't miss anything important. Progress has been uncomfortably slow
in other areas. We've had some UX discussion. Salt and Athan are both at
Open Source Bridge this week, and I'll be stopping by there today and
Friday. Hoping that soon we will finally have CiviCRM working, and I
need to get on top of legal issues still.

Looking forward to seeing this important progress from you soon.

Cheers




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


Re: [Snowdrift-discuss] Task unassignment

2016-05-25 Thread Aaron Wolf
On 05/25/2016 04:12 AM, fr33domlover wrote:
> Hello,
> 
> Recently this Taiga issue was created following feedback sent by Aaron:
> 
> https://tree.taiga.io/project/taiga/issue/4218
> 
> That explains under which conditions someone can claim a ticket, but what 
> about
> unclaiming?
> 
> Who can unclaim a ticket? Who can unassign someone else from a ticket?
> 
> --fr33
> 

These are decisions Taiga folks will make in the end, but I'd assume
that anyone who has permission to make assignments or claim a ticket for
themselves has the same permission to remove. It wouldn't make sense to
be able to claim but be unable to undo your claim.




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 take care of the blog

2016-05-19 Thread Aaron Wolf
On 05/19/2016 06:32 AM, Stephen Michel wrote:
> On Thu, May 19, 2016 at 12:59 AM, Bryan Richter 
> wrote:
>> On Wed, May 18, 2016 at 09:22:46PM -0600, Michael Siepmann wrote:
>>
>> On 05/18/2016 05:51 PM, Bryan Richter wrote: > On Tue, May 17,
>> 2016 at 12:13:34PM -0600, Peter Harpending wrote: >> On Tue, May
>> 17, 2016 at 10:21:23AM -0700, Bryan Richter wrote: >>> Website
>> work is blocked on taking care of the blog, so let's do >>> that.
>> We have to make some decisions, but first we need to agree >>> on
>> what purpose we are trying to achieve. >>> >>> To frame the
>> "purpose" discussion, I'll pose the first question: >>> Where does
>> the blog live? The decision flowchart starts with: >>> >>> 1. Blog
>> lives on the main site >>> 2. Blog lives somewhere else >>> >>>
>> Which shall it be? >>> >>> But let's not simply answer that
>> question. Let's start by >>> understanding why we have a blog, and
>> figure out what we need to >>> make it a success. From there, it
>> should be easier to agree on >>> this decision, and the ones that
>> follow. >>> >>> Here's my brainstorm for the blog's purpose: >>>
>> >>> 1. Show signs of life >>> 2. Keep people engaged >>> 3. Talk
>> about problems we're facing >>> 4. Talk about progress we've made
>> >>> 5. Add more content to the Internets, making it easier for >>>
>> people to find us in searches Would https://withknown.com/ be
>> worth considering? I'm considering using it myself since I like
>> the idea of the IndieWeb (http://indiewebcamp.com/) which I
>> learned about from Aaron - and it seems to be by far the easiest
>> way to do that. There's some info about it at
>> http://indiewebcamp.com/Projects too. 
>>
>> It looks pretty slick. I added it to a list on the User Story:
>> https://tree.taiga.io/project/snowdrift/us/61 Once we collect a few
>> more possibilities, I think it will be time to try to compare the pros
>> and cons.
> 
> Another possibility is Medium.com.
> 

No, Medium is *not* a possibility, period. They are NOT FLO. It is not
okay for us to disrespect the FLO status of projects like Ghost and go
with a proprietary blog service. We could not fork or self-host or
otherwise do whatever we need if Medium does things we don't want.

Medium encourages everyone to log in with Twitter, Facebook, or Google.
They are very much NOT a site that shares our values already.

> I believe they are only partially FLO (openness is one of their core
> values, but not with a code focus), but they have a wonderful UX, a
> snowdrift-compatible color scheme, and, I believe, an existing
> readership that is likely to be interested in Snowdrift.coop (though
> perhaps more from an angle of "this is an exciting new innovation" than
> "this is important for the FLO ecosystem" -- people who we can convert!).
> 



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 take care of the blog

2016-05-17 Thread Aaron Wolf
On 05/17/2016 10:21 AM, Bryan Richter wrote:
> Website work is blocked on taking care of the blog, so let's do that.
> We have to make some decisions, but first we need to agree on what
> purpose we are trying to achieve.
> 
> To frame the "purpose" discussion, I'll pose the first question: Where
> does the blog live? The decision flowchart starts with:
> 
> 1. Blog lives on the main site
> 2. Blog lives somewhere else
> 
> Which shall it be?
> 

My values:

* When Snowdrift.coop makes a careful decision about how to do something
like blogging, we at least consider how we can make it as easy as
possible for other projects to follow the same path (that's why having
it on the site for *any* project was originally proposed, because I hate
the idea that we do a ton of work and then conclude that any FLO project
has to reproduce all that same work themselves, I want to lower the
barriers to FLO project success)

* I want updates and blog things to be conceptually connected to
patronage enough that patrons and potential patrons feel well-informed
about the work their patronage supports

* I want a good blog for our own purposes for various reasons.

None of those require the blog being on the main site. If we decided to
use Ghost (one of the blog options more appealing to me as an end user
and in particularly liking the project and the project's values), and we
had a link to our blog on the main site (perhaps even a feed with titles
in a side-bar on the project, but not strictly necessary), and we made
it clear to other projects how to easily get set up with Ghost, then it
could address all my concerns.

Now, my *ideal* for blog software has certain features I'd want
including all the FLO ideals like working with LibreJS, working with
NoScript, having no privacy-invading analytics, having threaded 100% FLO
discussion section that has the full honor-system concepts, and so on. I
prefer this to be upstream rather than invent our own blogging software,
I just don't trust most upstream things to respect all these values, so
it's a trade-off.

I could imagine a Ghost blog that doesn't have direct discussions on
each page but instead links to a discussion topic for each post on a
Discourse forum that we have set up as best as we can to use our
honor-system.

That said, I'm not set on Ghost, it's just an example. It may or may not
be overkill. I defer to operations people somewhat. I have a biased weak
liking of having our stack be consolidated as much as possible and use
single-sign-on etc. whatever that means for our choices.

> But let's not simply answer that question. Let's start by
> understanding why we have a blog, and figure out what we need to make
> it a success. From there, it should be easier to agree on this
> decision, and the ones that follow.
> 
> Here's my brainstorm for the blog's purpose:
> 
> 1. Show signs of life
> 2. Keep people engaged
> 3. Talk about problems we're facing
> 4. Talk about progress we've made
> 5. Add more content to the Internets, making it easier for people
>to find us in searches
> 
> 

All those values are good. I'd add:

* Provide more personal sense to things with posts introducing team
members and discussing the project from a personal level (blog posts
have specific authors) versus wiki articles that don't work like that.

* Write about updates including references to new wiki articles and
other things in order to promote our FLO values etc

* After launch, write highlight other projects that use the system




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


Re: [Snowdrift-discuss] [Snowdrift-team] modifying donations to feed into the mechanism

2016-05-06 Thread Aaron Wolf
On 05/06/2016 06:55 PM, Bryan Richter wrote:
> [moving to discuss list]
> 
> On Fri, May 06, 2016 at 12:57:41PM -0700, Aaron Wolf wrote:
>> On 05/06/2016 12:10 PM, Bryan Richter wrote:
>>> On Fri, May 06, 2016 at 11:31:52AM -0700, Aaron Wolf wrote:
>>>> 
>>>>
>>>> In short, I read your comments above as though you have assumed we are
>>>> holding money. We cannot make that assumption at this time, except for
>>>> the MVP stage where we are the destination project ourselves anyway.
>>>>
>>>> Given the need to work through these issues and get further legal and
>>>> accounting professional assistance, my feeling is that this interaction
>>>> of actual payments is not the next step. I want to see everything
>>>> working with fake money first to know that everything else is in place…
>>>
>>> It is correct that I assumed we're holding money. But it's incorrect
>>> to assume that I believe we'll be holding other people's money.
>>>
>>> But I think I'm being too hasty. Whatever mechanism we choose now will
>>> be very hard to adjust later.
>>>
>>> Here's the situation: I don't think that having fake money first is
>>> feasible. We need to know the realities of working with *real* money
>>> in order to build a mechanism that has any practicality at all.
>>> Honestly, the "mechanism" is the easy part.
>>>
>>> Aaron, you've done a lot of research in this matter. What questions
>>> remain? Does anything prevent us from having a plan?
>>>
>>
>> Given a goal of building the actual long-term system (not merely the MVP
>> for ourselves), i.e. not having to redo it when we start adding
>> projects, we have to choose between the two transaction approaches
>> described on the wiki.
>>
>> Both are technically feasible.
>>
>> In summary:
>>
>> 1. charge in arrears
>> 2. We hold funds.
> 
> By far, the easier technical path is holding funds. If we're going to
> charge in arrears, it will be because we *really* can't charge up
> front.
> 

I recognize how much easier and more straightforward holding funds is
technically and conceptually, but the legality and related issues need
professional guidance with serious questions about how that will be
interpreted on that side.

> [This email is really long, because I ended up doing some
> hypothesizing. But the first part is pretty directly related to the
> question at hand.]
> 
> One big confounding factor for charging in arrears is aggregating
> charges and payouts. I've spent some time reading through the Stripe
> API and docs, and I can't find anything that hints at such a thing.
> So, that's a big technical challenge, because it involves technology
> we don't control. :) Without that strategy, we're stuck doing lots of
> micropayments.
> 

Oh, that's not an issue per Stripe at all. It matters not that you can't
find the docs per se. It may not be documented well. I've already been
in touch with Stripe folks and know precisely that this is a method they
support and they can just tell us exactly what to do. Effectively,
there's some part of their API where we just tell them certain numbers
and they make the charges we request.

The "technology we don't control" is any payment processing anyway. The
only quirky part that we need that not all payment processors would
support is the ability to take a list of charges and a list of payments
with both sides adding up to the same amount and process them all. Yes,
that does make us dependent on services that can handle that. However,
we can easily determine the numbers for each patron and each project on
our side. Again, this is just a matter of asking Stripe support which
API commands to send, and they'll guide us, I've already talked to them.


> Another confounding factor is dealing with declines. Does a patron
> with a recently-declined card count as a patron? If not, do we
> recalculate the payout on the fly? What about all the patrons who
> already paid at the higher rate?
> 

The way this works in general is pre-authorization. A card gets a
pre-authorization charge for the monthly budget initially but the final
charge goes through at the end when we know what the total charge will
be. This is standard stuff, and it's how Kickstarter and others operate.
The number of cards that will have successful pre-authorization but then
end up somehow not going through at the end is nominal and can be
disregarded as an issue. We'll still count everyone, and the existence
of a few failed payments isn't any different than if someone paid us
fully and then went to their credit card company and demanded a
charge-back 

Re: [Snowdrift-discuss] An opt-in we don't prefer could help Snowdrift design , ,

2016-05-05 Thread Aaron Wolf
On 05/05/2016 09:43 AM, mray wrote:
> 
> 
> On 02.05.2016 22:27, Michael Siepmann wrote:
>> This makes sense to me.  Offering a few options rather than just one can
>> change people's decision frame from "shall I do this?" (yes vs. no) to
>> "how shall I do this?" (option 1 vs. option 2. vs none of the above). 
>> Offering a one-time option can allow people to try engaging without
>> making more of a commitment than they feel ready for.  Of course it
>> would be good to include an option to receive occasional communications
>> as a result of the one-time donation, but important for that to be
>> opt-in with a clear promise that you can unsubscribe anytime.  And it's
>> certainly good to avoid making people feel at all pressured or
>> manipulated, which can threaten peoples' need for autonomy and trigger
>> psychological reactance (i.e. the motivation to avoid doing what you
>> feel pressured to do, even if you might have chosen to do it on your own
>> if you hadn't felt that someone was pressuring you).
>>
> 
> I also see some potential in letting people wiggle with their binary
> choice to be a patron and automatically un-patron after a certain amount
> of time. When they feel good about it they can start letting the switch
> in a permanent on or off.
> Ideally though, my hope would be that people don't need it and get how
> snowdrift works from day 1.
> 

Sure, but just to be clear: the idea isn't that this relates to people
knowing how snowdrift works or not. They could understand completely how
it works, and this option is still relevant. Just psychologically, the
presence of the one-time option makes people more comfortable with going
ahead with the sustaining pledge.

In decision science, a similar example is:

Choose product A for $50, product B for $80, or both products for $80.
With only the choice between A and both, many people choose A to save
money. When you add the stupid decision of B alone for the same price as
both, zero people choose that stupid option, but it makes far more
people choose to buy both. The presence of a stupid option makes the
more-expensive non-stupid option look like a good deal, so people go
with it.

The one-time vs sustaining option isn't a manipulative as that and has
some legitimacy existing, but the idea is precisely that the presence of
the choice gets more people to choose the one option we want them to
choose anyway.

I do think this was clear before, and I don't assume anyone totally
missed this, but I just wanted to reiterate since I wasn't certain.

>> I also think it may be helpful or even important to offer options for
>> fractional and multiple patronage.  For example, if a project has a lot
>> of a patrons so the monthly amount per patron is high, and I'm only an
>> occasional user of what that project produces but would like to support
>> it, I could opt to be 1/4 of a patron.  Or if a project I use heavily
>> and care a lot about doesn't yet have so many patrons, or has plenty but
>> I still want to give it extra support, I could opt to be a double or
>> triple patron, etc.
> 
> I'm against fractional/multiple patronage if our goal is to rely on the
> network effect. It would be adding a lever to the patrons input that is
> supposed to be the network effects job. We would give people the freedom
> to de-couple themselves from the network effect by the amount their choice.
> My impression is that we need to focus on having a simple logic that
> makes clear "we are all in this together" with a clear set of actions
> and consequences.
> 
> Cheers,
> Robert
> 
>>
>> Best,
>>
>> Michael
>>
>> Michael Siepmann, Ph.D.
>> *The Tech Design Psychologist*™
>> /Shaping technology to help people flourish/™
>> 303-835-0501   TechDesignPsych.com
>> <http://www.TechDesignPsych.com?id=esig>   OpenPGP: 6D65A4F7
>> <http://pool.sks-keyservers.net/pks/lookup?search=0x6D65A4F7=on=on=vindex>
>>  
>>
>> On 05/01/2016 10:11 PM, Aaron Wolf wrote:
>>> So, I learned from in research in traditional fundraising this
>>> interesting bit:
>>>
>>> This pertains to fundraisers wanting to get people to sign up as ongoing
>>> members where they donate monthly or annually (no matching in these
>>> traditional cases, of course — nobody has built the Snowdrift.coop model
>>> yet). If they include an opt-in checkbox for "one-time only donation" in
>>> what would otherwise assume that everyone signing up is going to be a
>>> sustaining member… then the mere presence of that opt-in choice results
>>> in *more* people becoming sustaining members!
>>>
>&g

Re: [Snowdrift-discuss] An opt-in we don't prefer could help Snowdrift design , ,

2016-05-02 Thread Aaron Wolf
On 05/02/2016 02:34 PM, Stephen Michel wrote:
> On Mon, May 2, 2016 at 4:27 PM, Michael Siepmann
> <m...@techdesignpsych.com> wrote:
>> On 05/01/2016 10:11 PM, Aaron Wolf wrote:
>>> So, I learned from in research in traditional fundraising this
>>> interesting bit:
>>>
>>> This pertains to fundraisers wanting to get people to sign up as ongoing
>>> members where they donate monthly or annually (no matching in these
>>> traditional cases, of course — nobody has built the Snowdrift.coop model
>>> yet). If they include an opt-in checkbox for "one-time only donation" in
>>> what would otherwise assume that everyone signing up is going to be a
>>> sustaining member… then the mere presence of that opt-in choice results
>>> in *more* people becoming sustaining members!
>>>
>>> In other words, when people feel they aren't forced into being
>>> sustaining donors but have a choice to do one-time-only, they end up
>>> feeling more comfortable with going ahead and becoming sustaining
>>> members after all.
>>>
>>> So, we could use this idea in our design. We'd provide an opt-in choice
>>> to participate only once for just the next month's pay period. We'd set
>>> it up so that we don't encourage people to choose that. But maybe this
>>> would end up helping more people accept the normal sustaining pledge
>>> that we want everyone to go with…
>>
>> This makes sense to me.  Offering a few options rather than just one
>> can change people's decision frame from "shall I do this?" (yes vs.
>> no) to "how shall I do this?" (option 1 vs. option 2. vs none of the
>> above).  Offering a one-time option can allow people to try engaging
>> without making more of a commitment than they feel ready for.  Of
>> course it would be good to include an option to receive occasional
>> communications as a result of the one-time donation, but important for
>> that to be opt-in with a clear promise that you can unsubscribe
>> anytime.  And it's certainly good to avoid making people feel at all
>> pressured or manipulated, which can threaten peoples' need for
>> autonomy and trigger psychological reactance (i.e. the motivation to
>> avoid doing what you feel pressured to do, even if you might have
>> chosen to do it on your own if you hadn't felt that someone was
>> pressuring you).
>>
>> I also think it may be helpful or even important to offer options for
>> fractional and multiple patronage.  For example, if a project has a
>> lot of a patrons so the monthly amount per patron is high, and I'm
>> only an occasional user of what that project produces but would like
>> to support it, I could opt to be 1/4 of a patron.  Or if a project I
>> use heavily and care a lot about doesn't yet have so many patrons, or
>> has plenty but I still want to give it extra support, I could opt to
>> be a double or triple patron, etc.
> 
> I think the concept of fractional patronage is confusing; I also think
> too many options would be problematic. However, I like the idea of
> offering 3 levels: One-time donation, Ongoing donation at normal level,
> Ongoing donation at higher level. We could even incorporate elements of
> the original formula, if the "higher level" is 4x and you get matched
> like 2 patrons. I think we'd avoid the complexity of the original
> formula that way too, because we don't need to explain the way patron
> amount rises with the root of donation amount; we just say,
> "Super-patrons count for 2 patrons and donate at 4x the normal level".
> 

After MVP success, that sort of additional functionality is worth
considering, but the core issue remains: it's very weird to say "there
are X patrons, but an effective X+Y patrons because Y patrons are
donating at a higher level" and then on top of that the questions about
whether higher-level is actually normal etc etc. It just adds so much
overhead to the explanations of things.

> How do 1x pledges work at a technical level? Do they still need to
> create an account? Do we just bill them once and eat the fees?
> 
> Maybe that's still too much complexity. If so, we can drop the
> "higher-pledge-level-counts-as-multiple-patrons idea. Are either the
> ideas of one-time pledges or super-patronage MVP?
> 
> 

Neither concept is strict MVP, but the one-off opt-in is substantial
enough in terms of *potential* increase in conversion, that it warrants
research and consideration for even MVP or soon after. Again, the idea
isn't that we want anyone to do one-offs per se, the idea is that
providing this option has been shown to incre

Re: [Snowdrift-discuss] An opt-in we don't prefer could help Snowdrift design , ,

2016-05-02 Thread Aaron Wolf
On 05/02/2016 01:27 PM, Michael Siepmann wrote:
> This makes sense to me.  Offering a few options rather than just one can
> change people's decision frame from "shall I do this?" (yes vs. no) to
> "how shall I do this?" (option 1 vs. option 2. vs none of the above). 
> Offering a one-time option can allow people to try engaging without
> making more of a commitment than they feel ready for.  Of course it
> would be good to include an option to receive occasional communications
> as a result of the one-time donation, but important for that to be
> opt-in with a clear promise that you can unsubscribe anytime.  And it's
> certainly good to avoid making people feel at all pressured or
> manipulated, which can threaten peoples' need for autonomy and trigger
> psychological reactance (i.e. the motivation to avoid doing what you
> feel pressured to do, even if you might have chosen to do it on your own
> if you hadn't felt that someone was pressuring you).
> 
> I also think it may be helpful or even important to offer options for
> fractional and multiple patronage.  For example, if a project has a lot
> of a patrons so the monthly amount per patron is high, and I'm only an
> occasional user of what that project produces but would like to support
> it, I could opt to be 1/4 of a patron.  Or if a project I use heavily
> and care a lot about doesn't yet have so many patrons, or has plenty but
> I still want to give it extra support, I could opt to be a double or
> triple patron, etc.
> 

Thanks, Michael.

For reference, the fractional or multiple patronage ideas make total
sense and were included in the initial planning of the whole system.
However, they are so much more complex in terms of the variables and
ramifications, that we came to realize it was totally impractical to
include any of those elements in the MVP launch. They are basically
tweaks and ideas for how to fine-tune the system once it becomes fully
successful already.

The one-time opt-in UI feature is simple enough technically and
conceptually that we could include it in MVP even. We could even
consider A/B where it is shown for some people and not for others and
see what impact it has…


> Best,
> 
> Michael
> 
> Michael Siepmann, Ph.D.
> *The Tech Design Psychologist*™
> /Shaping technology to help people flourish/™
> 303-835-0501   TechDesignPsych.com
> <http://www.TechDesignPsych.com?id=esig>   OpenPGP: 6D65A4F7
> <http://pool.sks-keyservers.net/pks/lookup?search=0x6D65A4F7=on=on=vindex>
>  
> 
> On 05/01/2016 10:11 PM, Aaron Wolf wrote:
>> So, I learned from in research in traditional fundraising this
>> interesting bit:
>>
>> This pertains to fundraisers wanting to get people to sign up as ongoing
>> members where they donate monthly or annually (no matching in these
>> traditional cases, of course — nobody has built the Snowdrift.coop model
>> yet). If they include an opt-in checkbox for "one-time only donation" in
>> what would otherwise assume that everyone signing up is going to be a
>> sustaining member… then the mere presence of that opt-in choice results
>> in *more* people becoming sustaining members!
>>
>> In other words, when people feel they aren't forced into being
>> sustaining donors but have a choice to do one-time-only, they end up
>> feeling more comfortable with going ahead and becoming sustaining
>> members after all.
>>
>> So, we could use this idea in our design. We'd provide an opt-in choice
>> to participate only once for just the next month's pay period. We'd set
>> it up so that we don't encourage people to choose that. But maybe this
>> would end up helping more people accept the normal sustaining pledge
>> that we want everyone to go with…
>>
>> Incidentally, besides hearing thoughts from others, I'm not clear in our
>> new project management where is the best place to write down this idea
>> so that it gets discussed and can then be something our research and
>> design folks can consider and test…
>>
>> Cheers,
>> Aaron
>>
>>
>>
>> ___
>> 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
> 




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


[Snowdrift-discuss] An opt-in we don't prefer could help Snowdrift design , ,

2016-05-01 Thread Aaron Wolf
So, I learned from in research in traditional fundraising this
interesting bit:

This pertains to fundraisers wanting to get people to sign up as ongoing
members where they donate monthly or annually (no matching in these
traditional cases, of course — nobody has built the Snowdrift.coop model
yet). If they include an opt-in checkbox for "one-time only donation" in
what would otherwise assume that everyone signing up is going to be a
sustaining member… then the mere presence of that opt-in choice results
in *more* people becoming sustaining members!

In other words, when people feel they aren't forced into being
sustaining donors but have a choice to do one-time-only, they end up
feeling more comfortable with going ahead and becoming sustaining
members after all.

So, we could use this idea in our design. We'd provide an opt-in choice
to participate only once for just the next month's pay period. We'd set
it up so that we don't encourage people to choose that. But maybe this
would end up helping more people accept the normal sustaining pledge
that we want everyone to go with…

Incidentally, besides hearing thoughts from others, I'm not clear in our
new project management where is the best place to write down this idea
so that it gets discussed and can then be something our research and
design folks can consider and test…

Cheers,
Aaron

-- 
Aaron Wolf
co-founder, Snowdrift.coop



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


[Snowdrift-discuss] Open Source Bridge proposals due 13th

2016-04-10 Thread Aaron Wolf
http://opensourcebridge.org wonderful conference in Portland (where I
am). It is my second favorite of all regular conferences I've been to
after LibrePlanet, and it surpasses LibrePlanet in many regards. I hope
to attend, but can't think about it too much right now. Maybe I'll put
in a proposal but we'll see.

I'd love if others able to go to the conference put in talk proposals
about things relevant to Snowdrift.coop success. You can put in multiple
proposals and see if one of them get accepted. Here's the best resource
for good submissions: https://www.harihareswara.net/sumana/2016/03/29/0

Whether or not you submit a talk and get accepted, anyone can go to the
conference free if you volunteer 8 hours of time. I'm hoping to see if
they have a child-care set up again and may volunteer to help there and
having it may make my own attendance most feasible.

Cheers

-- 
Aaron Wolf
co-founder, Snowdrift.coop



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


Re: [Snowdrift-discuss] Sandstorm on Oasis

2016-03-24 Thread Aaron Wolf
On 03/24/2016 11:31 AM, Bryan Richter wrote:
> We've sort of put Sandstorm on a back burner, but I think there is a
> much better solution to consider:
> 
> https://docs.sandstorm.io/en/latest/administering/for-work/#special-pricing
> 
> Basically, we should just ask for free hosting on their managed
> service, Oasis.
> 
> 1. We don't have to manage it at all
> 2. HTTPS comes automatically
> 3. Domain will (probably) be https://snowdrift.sandstorm.io
> 
> 

Sounds good to me. Go ahead and ask asheesh about this. I like the idea
of having access to Sandstorm to explore things and use tools here and
there as useful.



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


Re: [Snowdrift-discuss] Weekly Tactical Meeting Today, 3/21, 19:00-20:00UTC

2016-03-21 Thread Aaron Wolf
On 03/21/2016 08:46 AM, Stephen Michel wrote:
> Important note: for folks outside the US, you may not have passed
> daylight savings yet, so this time may be offset 1 hour. It'll be back
> to normal next week.
> 
> We're switching away from OpenProject, so no link this week. See the
> long "state of project management" email for discussion about meeting
> planning/minutes. There's a couple open questions and I'd love feedback!
> 
> 

And this 19UTC meeting will be at https://meet.jit.si/snowdrift

(please always include that link in announcements)




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


Re: [Snowdrift-discuss] Page development: current status

2016-03-14 Thread Aaron Wolf
On 03/14/2016 11:49 AM, Mica Semrick wrote:
> Hi Bryan,
> 
> I will be doing some work on these! Unfortunately my schedule does not
> permit me to attend any meetings, so these types of mails are very
> useful to me.
> 
> I'd like to touch base with anyone else who is going to author/edit. Let
> me know who you are!
> 
> Best,
> mica
> 

Great, Mica! Thanks for the note. I hope others will weigh in, but I
will clarify that I will be involved in authoring the content on the
pages that communicate thins about the project such as /about and
/how-it-works and related.

Overall, our plan is to get all the tasks and items sorted in Open
Project at http://shovel.snowdrift.coop (unless we decide soon to
consider a different project management tool, we're looking a little at
https://taiga.io ). Once that's better organized, it will make it
easiest for everyone to get to work on things.

Cheers,
Aaron


> On March 14, 2016 11:35:58 AM PDT, Bryan Richter 
> wrote:
> 
> Below is a list of all the pages needed for launch. Aaron and I looked
> at most of them and brainstormed what they needed to be complete. I
> added completion percentage numbers to all of them, which are pleasant
> little fictions.
> 
> What would be *lovely* is to somehow get this information added into
> OpenProject. Any ideas how best to do that?
> 
> 
> 
> Here is a summary (actual are tasks listed further below):
> 
> [] /u   [unprocessed]
> [] /u/#user [unprocessed]
> [  0%] /about
> [  0%] /about/contact
> [  0%] /about/team
> [  0%] /about/press
> [  0%] /dashboard
> [  0%] /transactions
> [  0%] /pledges
> [  1%] /how-it-works/sustainable-funding
> [  1%] /how-it-works/co-op
> [  5%] /how-it-works/network-effect
> [  5%] /p/snowdrift
> [ 15%]
> /how-it-works/flo
> [ 30%] /p
> [ 50%] Auth Subsite
> [ 60%] /terms
> [ 60%] /privacy
> [ 60%] /trademarks
> [ 60%] /how-it-works
> [ 75%] /donate
> [ 75%] /sponsors
> [ 75%] /honor-pledge
> [ 95%] /merchandise
> [ 95%] /search
> [100%] /welcome
> [100%] /js-licenses
> [100%] Static Subsite
> [100%] /favicon
> [100%] /robots.txt
> 
> Using some totally untrustworthy math (an unweighted average), this puts
> total completion at ~ 40%.
> 
> This is just *pages*. It doesn't take into account any of the
> architecture components, like the funding mechanism, notifications,
> and the CSS layout and typography frameworks.
> 
> 
> 
> Here is the full list of tasks we brainstormed:
> 
> - Pages
>   - /welcome
>   - /terms
> - content exists as Markdown
>  
> - /privacy
> - content exists as Markdown
>   - /trademarks
> - content exists as Markdown
>   - /donate
> - Is interim page; may disappear with launch
> - Add Ikomi's bullet style from master
> - Fix missing wiki links: "volunteering"
> - Remove alpha warning
>   - /merchandise
> - Fix missing wiki link: "volunteering"
>   - /sponsors
> - Needs user data from prod database
>   - /js-licenses
>   - /honor-pledge
> - Fix missing wiki links: "conduct", "honor-users", "honor".
>   - /how-it-works
> - Needs Communications work (same with all subpages below)
>   - /how-it-works/flo
> - Will reference wiki content: "economics", "snowdrift",
>   "project-requirements"
>   - /how-it-works/network-effect
>   - /how-it-works/sustainable-funding
>   - /how-it-works/co-op
>   - /about
>   - /about/contact
>   - /about/team
>   - /about/press
>   - /search
>
> - Discussion needed: get UX consensus on its existence for launch
>   - Auth Subsite
> - Add /reset-passpharse, /create-account, /change-passphrase,
>   /user-reset-passphrase to page.
>   - /dashboard
>   - /transactions
>   - /pledges
>   - /p
> - Needs messaging: "Coming soon"
> - Will take concepts from wiki page "project-requirements"
>   - /p/snowdrift
> - Needs working mechanism
> - Needs Communication updates
> - Discussion needed: Do we need /p/snowdrift/updates and
>   /p/snowdrift/transactions?!?
>   - Static Subsite
>   - /favicon
>   - /robots.txt
> - Post-launch followup
>   - Consider removing /donate
>   - Consider redesign for /sponsors
>   - Update/prune list of JS libraries on /js-licenses
> 
> 
> 
> Discuss mailing list
> 

Re: [Snowdrift-discuss] Governance Mtg March 7 @ 19:00UTC

2016-03-06 Thread Aaron Wolf
On 03/06/2016 06:25 PM, Stephen Michel wrote:
> That's today/tomorrow, depending on when you read this. We will:
> 
> - Implement the core of Holacracy
> - Discuss which parts of Holacracy we shouldn't implement and any
> additional policies we may want.
> 
> To ensure we have time, there are 3 hours blocked out. Stop by for
> however long you can afford to; any participation is welcomed.
> Prioritize attending from 20:00-21:00UTC.
> 
> http://shovel.snowdrift.coop/meetings/29
> 
> Cheers,
> Stephen
>

To clarify, I optimistically do not expect we need a 3 hour meeting.
That seems excessively long, and the structure is supposed to be very
efficient. We will aim to get all the important concerns addressed in
1-2 hours, hopefully within 60-90 minutes.




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


Re: [Snowdrift-discuss] steps that lead to working mechanism

2016-03-01 Thread Aaron Wolf
On 03/01/2016 12:44 PM, Bryan Richter wrote:
> On Tue, Mar 01, 2016 at 12:16:22PM -0800, Aaron Wolf wrote:
>>
>> So, I have a bigger concern to make sure we consider: Lots of things
>> currently reference user id such as links for sponsors and elsewhere
>> including CiviCRM. There are some reasons to dislike the way the
>> arbitrary id numbers are used compared to other options, but it may
>> just be the most sensible.
>>
>> So, as we rebuild via a dev reimplemention, I want us to either use
>> the *same* user list (i.e. migrate it over, question being how to
>> deal with sync issues going forward)
> 
> I believe I addressed this. Part of the reason we are keeping the old
> site around is because all the data relating to users is, in fact,
> valuable. When the time comes, it will be migrated or incorporated
> appropriately.
> 
>> ... make it clear that the dev thing is just testing and may get
>> periodically wiped and that the main site is still the real one for
>> now,
> 
> This is why the plan is to operate the new site under
> "dev.snowdrift.coop".
> 
>>
>> So, I imagine we end up with a nice working site that has a clean
>> database with no users or anything and only the core functions we
>> need or at least things separated into subsites adequately etc. We
>> make all the cleanest decisions we can, like the table being "users"
>> instead of "user" for example, maybe the newer environment
>> variables, certainly the best newest auth stuff and no Persona
>> anything… and then once we're comfortable with that, we do a
>> migration where we copy over the users from the main site keeping
>> the old database for reference but migrating only the columns that
>> still apply to the new updated site.
>>
>> The significant thing here is keeping the users and their id
>> numbers. I know there's a way to migrate the auth hash stuff so that
>> we move to the stronger newer hashing… Anyway, we don't need to
>> handle every aspect of this right away, just need the plan to be
>> clear.
> 
> Don't worry about these things right now.
> 

Okay sounds good. The only reason I felt concerned was because I'm
*okay* with losing some data such as precise wiki version history (not
that I *want* to lose it, but I don't want preservation to get in the
way of more important progress). So, I know that the overall data is
understood as valuable, I just wanted to make it clear that the
particular user ids actually matter, whereas the id of the snowdrift
project, for example, can change because we refer to it by "snowdrift"
and never by it's database id. So the user id specifically seemed a
non-obvious thing to point out as a concern.

I'll not worry about this further. I definitely support the proposed
direction and would be happy to see it push forward ASAP.





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


Re: [Discuss] user stories vs specs

2016-02-26 Thread Aaron Wolf
On 02/26/2016 01:29 PM, Bryan Richter wrote:
> Yesterday while fleshing out user stories, the question came up of
> whether or not user stories can capture everything, or whether some
> information should be deferred to specs.
> 
> In my opinion, separate specifications are needed because user stories
> only capture features. It is not a user story that users have unique
> ids in the database, to name a trivial example. Perhaps I should list
> a more interesting example: It is not a user story that a single,
> reusable library handles all alerts for the system. Stories will talk
> about *specific* alerts, or even possibly about features of alerts in
> aggregate, but they will never say "alerts are handled by src/Alert.hs
> which exports the following symbols: ..."
> 
> If I'm just arguing semantics let me know.
> 
> It's certainly possible that all *site features* can be captured in user
> stories alone.
> 
> 

I think the point is that the existence of features and specs should be,
ideally, justified by user stories. In a silly sense, a story for the
alert backend could be one with the subject as a developer.

Really, I think specs make total sense as something additional and
separate from user stories, but we should ideally have references in the
specs to the user story source of things that do relate to user stories.

Broadly, we should use whatever organizing approaches successfully lead
us to MVP and not be dogmatic. We should not make specs that don't help
us reach MVP. We shouldn't get into obsessive organizing in pursuit of
some perfect structure where nothing is at all ambiguous. But neither
should we reject the writing down of specs, plans, whatever in whatever
form is clearly helping us progress. We should recognize all of this as
sets of tools and use the best tools whenever appropriate, just never
solely because of some dogma about the tools.




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


Re: [Discuss] on prioritizing next steps for Snowdrift.coop

2016-02-18 Thread Aaron Wolf
On 02/18/2016 12:24 AM, Stephen Michel wrote:
> On Thu, Feb 18, 2016 at 12:18 AM, char...@thefnf.org wrote:
>> Before you dive into process for process sake and die a death of a
>> thousand cuts by the toolchain... I'm seeing lots of massive brain
>> dumps, grandiose plans, long lists. That's a huge amount of
>> information. You'll die from analysis paralysis. I used to do that as
>> well (in my earlier investor/founder experiences). None of those ever
>> shipped or even came close.
> 
> I'm with Charles, here. Before SCALE I felt like we were making
> progress. Now I feel like we're stalled. I'll follow his advice right
> here. I propose we head immediately for alpha. I propose the following:
> 
>> How about a vastly simplified approach (can still use the tools of
>> course but in a more streamlined fashion) 1) Define core personas.
>> (project patron, project contributor).
> 
> Core persona #1: Project Patron. Let's use Jay [0].

I'm not sure Jay is the best, but maybe

> Core persona #2: Project contributor. Let's use Mara[1].

I wrote Mara as a Snowdrift volunteer / team member. When Charles said
"Project contributor" he meant what we call "project team member" i.e.
someone connected to a different project, not Snowdrift.coop itself.

> 
>> 2) Define what an minimally viable product would be for those two
>> personas.
> 
> Jay comes to the site, reads the introductory materials, and quickly
> becomes enamored of the concept of coordinating to fund public goods.
> He's busy and has no technical skills, so he decides to support our
> development monetarily instead. He creates an account and pledges as a
> patron of Snowdrift.coop.
> 

Okay, I see, we're using Snowdrift.coop as the project initially, which
is okay. At some level, we don't need vague personas for us as we can
use real people, but I'm not sure what the advice would be about that.

> Requirements:
> - [TODO] Good introductory materials
> - [DONE] Ability to create an account

additional [TODO] (well to verify): authorizing funds

> - [TODO] Project page with clickable pledge button
> - [TODO] Functioning mechanism for a single project
> - [TODO] A way to view current donation per month.
> - [TODO] Functioning "un-pledge" button
> - [TODO] Decide how to process payments
> - [TODO] Legal requirements I don't know about?
> 
> Mara comes to the site. She too reads the introductory materials and
> becomes enamored of us. She wants to put her technical skills to use, so
> she fills out a volunteer interest form. (from here, we can help point
> her in whatever direction necessary).
> 
> Requirements:
> - [TODO] Good introductory materials
> - [DONE, or WIP?] A good, functioning, volunteer form.
> 

Volunteer stuff isn't MVP (but it's the broad category of "stuff that
may or may not help us get to MVP). Don't worry about that here anyway.
The funding for Snowdrift.coop is for our own immediate costs right now,
we don't need to fund hypothetical new person.

I think we should indeed focus on our own immediate needs, and so we
don't need to have Mara the persona for this.

But moving beyond us to outside projects, we need to make sure we have
the requirements clear about what's needed for outside projects to sign
up and become able to receive pledges.

>> 3) Spend three weekends (and 3 hours per day between weekends)
>> building the minimally viable product. If it's more than a man month,
>> kill it. Aggressively fight scope creep etc. (repeat the above for the
>> corporate entity as well).
> 
> Yes, I'm missing a lot of todo's here. Yes, that's the point. That's why
> it's called the MINIMUM viable product.
> 
> Does this sound good to everybody? Try not to write an essay in
> response, we can do that ria IRC :)
> 
> [0] http://shovel.snowdrift.coop/projects/snowdrift/wiki/Jay
> [1] http://shovel.snowdrift.coop/projects/snowdrift/wiki/Mara
> 
> --- Email Policy: http://stephenmichel.me/email
> 
> 

Thanks, Stephen. Good direction. I want TODAY to start putting these
things into Open Project and then getting to WORK.

-Aaron




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


[Discuss] on prioritizing next steps for Snowdrift.coop

2016-02-17 Thread Aaron Wolf
So, we had this idea of putting everything in a big list and sorting it.
Now that I've started, I think continuing that plan is dumb. Not that
the process hasn't helped, but I want to shift how we move forward now.

We have a huge list, a few specifically. We have tickets already, we
have stuff noted. The issue we had relate to needing the top priorities
clearly identified (but not about having the rest of the
lower-priorities all sorted by priority) and to clarifying the
motivations for each issue so that the details could be determined
clearly by everyone involved.

For example, we know that making the how-it-works introductory material
effective and complete is a high priority. The trouble came from having
the tasks be "let's say X" or an illustration made or a wording proposed
without having a consensus on how to evaluate each proposal.

So, now we have some personas:
http://shovel.snowdrift.coop/projects/snowdrift/wiki/Personas_for_user_stories

And I started writing out user stories to sort:
http://flurry.snowdrift.coop:2040/shared/bWJqTz9yLHJbuj7W1FMd28_QfJBt3MaW7J4uyt8oxh5

And I think continuing in this direction is good. So, we can think about
personas coming to see the how-it-works stuff and think more about why
it needs to have certain elements. We should take this priority item and
figure out in Open Project how to finalize some stories around what the
how-it-works pages should accomplish. Then we can figure out the minimum
needed to accomplish the issues, and we should better figure out how to
evaluate each decision.

Using that example, it's clear that the how-it-works pages could be
really long because there's so much to say. But we need them to be
concise and get people to actually read them and get the idea as quickly
as possible. The questions are: what ideas are essential? What level of
vagueness is acceptable initially around what? And user stories can help
us think through this. Open Project organizing should, hopefully, have
ways for us to separate all the steps needed.

So, here's how I see going forward: we start with things we *know* to be
high priority. We work through our new process with those items. Among
high-priority items, we can use the functions in Open Project to
sometimes say "oh, this new item is highest priority really" or "this is
high but lower than that other item". But we only need to do this with
clearly high priority items. We can all agree to prioritize things
according to what's in Open Project, and anything else still might
happen spontaneously but mostly won't be a focus.

I'd like to get started ASAP. I want help from those with thoughts or
guidance about each step of taking known items (let's go with
how-it-works pages as the first example) and eventually having a totally
organized way to identify all the appropriate stories and tasks in Open
Project.

Best,
Aaron
-- 
Aaron Wolf
co-founder, Snowdrift.coop



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


Re: [Discuss] OpenProject Work Packages Workflow

2016-02-12 Thread Aaron Wolf
On 02/12/2016 04:44 PM, Bryan Richter wrote:
> On Fri, Feb 12, 2016 at 02:12:59PM -0800, Aaron Wolf wrote:
>> On 02/12/2016 02:00 PM, Bryan Richter wrote:
>>>
>>> Hmm, yeah, maybe co-op/money/website are a lot more interdependent
>>> than I was thinking. That makes me wonder — what is the plan for
>>> co-op and money? If they are going to impact site development, and
>>> be impacted by it, we need a holistic roadmap. I looked around at
>>> the Next and Strategy wiki pages and didn't find any mention of a
>>> plan. I'm pretty sure there *is* a plan (part of which is drafting
>>> bylaws..?).
>>>
>>
>> We need the Bylaws first and foremost, and there's work I need to do
>> (partly since Jon, who had done some, hasn't been active lately).
> 
> I think it would be good to list these tasks, whatever they may be, in
> OpenProject.
> 
> Regarding the tech roadmap, I have some more questions about the
> relationships between co-op requirements and website requirements.
> These questions may be rather pedantic, but my hope is to have a
> ridiculously clear set of priorities.
> 
>>> Will there be requirements put on the website to achieve any of that
>>> vision (non-profit, cooperative, both)?
>>
>> The website in terms of the projects we support will need to follow the
>> legally stated mission.
> 
> So: does the website need to follow the mission before incorporation,
> or can it follow afterwards as a work-in-progress? If the former, does
> that mean we must be funding other projects before we can incorporate?
> (I highly doubt it, but like I said, I want the relationships to be
> stunningly clear.)
> 
>> Otherwise, we will need to have infrastructure one way or the other
>> for managing the board meetings and membership contracts etc. i.e.
>> the basic operations of running a co-op.
>>
>> ...
>> On the tech infrastructure side, we need to have the systems that
>> recognize co-op members in terms of board elections and other voting.
> 
> Again: is this infrastructure a hard requirement for our website
> before incorporation, or is it something we can fulfill by other
> means first?
> 
> I am trying to determine what, exactly, the MVP is. If we can be a
> co-op without these features in our website, then it would not be
> 'minimal' to have them.
> 
> If we can AVOID having these features until later, that would give a
> lot more flexibility to the tech roadmap, and allow us to hit the
> milestone of funding ourselves (!!) a lot sooner.
> 
> 

In short: we *need* to have the co-op governance working ASAP. That
means that there are the required roles, the bylaws are set, and we are
in fact having meetings and elections. We are not legally required to
have these things just to take in money (we're already getting
donations), but they really should be set by the time we are saying in
any real sense that we are "open for business", and ideally *sooner*.

None of that says anything about how we do these things (like whether
the manner in which we hold meetings and elections is connected to the
core website or not), as long as it follows the bylaws (which must
follow legal requirements).

A top priority is indeed to finish making decisions about bylaws that
our lawyer wants us to make and then get that final stuff back to her.

I'm about to be a guest on a podcast again, but tomorrow I should be
able to get this stuff onto the OpenProject wiki or something. Some of
it is already on the main wiki. We just need a way to all discuss and
come to decisions so we finally have clarified stuff to hand off to the
lawyer. She wants us to have clear decisions like "what precisely
defines a project class member?" and similar things that were
inadequately precise.

___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss


[Discuss] Snowdrift weekly meeting in 45 minutes

2016-02-08 Thread Aaron Wolf
http://shovel.snowdrift.coop/meetings/6

We're organizing our meetings better via OpenProject. Today is just a
shorter check-in, and chance to bring up any immediate concerns, make
sure we're on the same page with things, on top of everything.

Cheers,
Aaron

-- 
Aaron Wolf
co-founder, Snowdrift.coop
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss


Re: [Discuss] Meeting minutes 2016-02-01

2016-02-01 Thread Aaron Wolf
On 02/01/2016 03:36 PM, Bryan Richter wrote:
> Thanks to setting up OpenProject, we now have a perfectly reasonable
> place to record minutes for meetings. Here is what I came up with for
> today's meeting:
> 
> http://shovel.snowdrift.coop/meetings/2
> 
> Any feedback on minutes format would be appreciated. Too terse?
> 
> p.s. to Aaron, Jason, and any other OpenProject admins: I went to
> http://shovel.snowdrift.coop/admin/roles to allow the 'Anonymous'
> role to view meetings. Without doing so, one would have to log in to
> view meetings.
> 

Thanks Bryan! The Decisions and Next Steps sections are superb, but they
should be *alongside* actual minutes that summarize the course of the
discussion (not all the things said, but a brief overview of how the
meeting went). Anyway, it's all a work in progress building these skills
and we'll continue to document and plan better.

Happy about this progress getting our organizing back on track. A year
ago, we kinda restarted with me handling everything alone with most
everyone involved being relatively new following our fund-drive and
prior people getting busy with other things. I'm happy with where we
are, some things are better, other areas we're still getting back on
track (meetings being a big part of that).

Cheers

___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss


Re: [Discuss] shutting down our sandstorm instance

2016-01-28 Thread Aaron Wolf
On 01/28/2016 02:28 PM, Bryan Richter wrote:
> We primarily wanted Sandstorm for Etherpad. However, Etherpad is a
> node.js based, JIT-compiled application. Sandstorm's security model
> requires each document to be running in its own, sandboxed copy of the
> app, and the JIT-ness apparently precludes such applications from
> sharing memory. Thus, each *document* uses 60-100MB when open.
> 
> We can't support that right now, so I plan on shutting down our
> Sandstorm instance in two weeks.
> 
> Perhaps we can run Etherpad *outside* of Sandstorm, if we still find
> ourselves wanting for a collaborative document solution.
> 
> P.S. These facts were confirmed by a friend of mine at a Sandstorm
> meetup in SF yesterday. They hope to solve the memory usage with
> "snapshotting" at some point.
> 

I think Sandstorm's clunky interface for sharing etc. and even seems
laggy as a user… I'm happy to skip it. It has promise, but feels not
great right now.

I made some notes about our tools:

IRC: *check* (we talked about embedding a client in the site sometime
though)

Jitsi meet: *check* use their instance

Etherpad: we don't have a good third-party host that we know we can rely
on, the updated one with in-line commenting is nice. Maybe we should run
it ourselves…

Wekan: probably run ourselves…

Redmine or OpenProject: user-stories, processing, sorting, project
management stuff, I guess should run ourselves

Wiki: need to separate wiki stuff out from our code, probably separate
the main articles for public-consumption stuff from the stuff that we
use for our organizing. I'd like to integrate Gitit eventually. I could
see using a wiki with Redmine/OpenProject or something for immediate
notes and internal organizing.

GitLab: *check* via git.gnu.io

Email lists: *check* but probably should move the announce stuff to
CiviCRM probably

CiviCRM: *check* but need better organizing, better access for people,
use the email announce functions, use hooks/API or something to
integrate potentially…

http://42.meup.org for image paste sharing…

We're still working on:

image repos, collaborative graphics work…

spec'ing of the site… will Redmine cover that?

Sorry for the dump of stuff, I guess ideally even Redmine might offer
better ways to process all this info vs just this mailing list?
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss


Re: [Discuss] Sandstorm Etherpad is a memory hog

2016-01-27 Thread Aaron Wolf
On 01/27/2016 02:29 PM, Bryan Richter wrote:
> Each Etherpad pad uses 60-100MB of memory when someone has it open.
> Right now there are four open pads, using a total of 27% of the
> system's memory.
> 
> I don't know if we can stand for that. Options? Thoughts?
> 

Naive non-tech-thought: That's kinda crazy. Is that costing us any extra
money? It doesn't use extra to have multiple people on the same pad does
it? Maybe we can check with norms about memory use for etherpad and
determine whether Sandstorm is adding memory. If Etherpad would be the
same either way, then it's just how it is and we need to avoid excessive
use of it…

___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss


[Discuss] initial SCaLE follow-up snowdrift meeting in an hour

2016-01-25 Thread Aaron Wolf
Last minute reminder, video chat meeting 20:00 UTC (1 hour from now):
https://meet.jit.si/snowdrift

First of a lot of discussions we'll have about going forward given
valuable perspectives and connections following our booth at the
Southern California Linux Expo.

Cheers!

-- 
Aaron Wolf
co-founder, Snowdrift.coop
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss


[Discuss] Snowdrift meeting in 2 hours, final pre-SCALE

2016-01-18 Thread Aaron Wolf
Hi everyone,

We've been juggling a lot of things, won't go into details right now.

In 2 hours, 20:00 UTC (12 noon pacific), we'll have the final weekly meeting 
before SCALE this weekend.

Come join us at https://meet.jit.si/snowdrift

Cheers,
Aaron
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss


Re: [Discuss] Pricing experiments & launch timeframe

2015-10-20 Thread Aaron Wolf


On 10/20/2015 06:01 AM, Dave Crossland wrote:
> Thought this was good:
> http://conversionxl.com/pricing-experiments-you-might-not-know-but-can-learn-from/
> 

I was already familiar with most of that, but good to see such a clear
compilation. I can't stand those dogmatic capitalist folks who argue
that the market makes all prices become this theoretical rational
perfect price. It really bugs me that the article and the comments all
think this stuff is great though. There's only tiny little admissions
here and there that all this manipulation may be ethically questionable.

I deal with these things as a private music teacher. I hate it. The
relation to me being the best teacher around has nothing to do with
whether I charge the most or how all the pricing works. It's all so sleazy.

Anyway, not sure if we should add more of these references, but I'm
going to post that link in the comments for consideration on this page:
https://snowdrift.coop/p/snowdrift/w/en/markets-and-prices

Perhaps others would like to read that and clean it up, add to it if it
seems warranted.


> Trufont.github.io <http://Trufont.github.io> is gathering steam to
> replace fontforge as the leading libre font editor, so I'm looking at
> ways to raise funds to accelerate development. Will snowdrift be ready
> in November?
> 

Obviously work is active, but I can't see us being operating in
November. I would love to say otherwise, but there's so much to do still.

Thanks for the thought, and the push. We will work to get this thing
going ASAP!!

-- 
Aaron Wolf Snowdrift.coop <https://snowdrift.coop>
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss


Re: [Discuss] [Funding Mechanism] How to accommodate lower and higher pledge levels

2015-10-19 Thread Aaron Wolf


On 10/19/2015 08:20 AM, Stephen Michel wrote:
> In short, I don't believe we actually need any change to the mechanism;
> we just need to lower the minimum and encourage donation at
> above-minimum levels.
> 
> We should do this by keeping in mind that *the average user will tend to
> stick with the defaults.* Therefore, if we set the recommended pledge
> level above the minimum, so long as that pledge level is reasonable (ie,
> easily within the user's budget), they will stick with that donation
> level. I propose the following. Note: numbers are rather arbitrary, I
> just wanted to give a concrete example/idea.
> 
> let n refer to the number of users.
> 
> - Lower the minimum contribution to $1 per 5000 users.

There's no basis for you to speculate that this lower minimum makes any
sense. These types of changes are only sensible once we can operate and
see how the numbers play out. Our current baseline is as good an
appropriate guess and easier to calculate and explain.

I think you need to read https://snowdrift.coop/p/snowdrift/w/en/limits


> - For small n (< 100), the recommended contribution is $1 per 1000 users.
> - For n <= 100, the recommended contribution is the average of other
> users' contribution.

We don't want to recommend people counteracting the network effect. That
would mean a message to others that says "if you join, others will
adjust their pledge downward and actually *not* match you really".

>   - This is presented to the user as "match other users 1:1"
>   - The user has an option to match at a different rate, but it's not
> highlighted visually.
> - If a user does opt to change their rate, the following message is
> displayed:
>   - "This will [increase/decrease] the recommended donation[!/.]"
> 
> Hopefully this allows for all of the following:
> - A social incentive to donate more (increase the recommended donation).
> - A way to donate less with a reasonable social "penalty."
>   - if there's no "penalty," people may try to calculate the "best deal"
> of matching, ie, always donate the minimum.
>   - if there's too much "penalty," it may dissuade people who actually
> can't afford it from donating.
> - An elegant way to handle higher and lower contribution levels (ie,
> adds little complexity).
> - An intuitive way to present higher and lower donation levels to users.
> 
> Thoughts?

All these goals are captured in our initial formula:
https://snowdrift.coop/p/snowdrift/w/en/formula
It has all the right properties to encourage larger pledges, discourage
reducing your pledge, *allow* reducing your pledge… and we even
originally started with a minimum that was a tenth the size of the
current proposed minimum. So your thinking is exactly where we started
with all this.

The problem is that all this just leads to too much complexity, too much
to explain, too many qualifications over the plain pledge concept, and
so we really need to focus on launching without all this for now. The
explanation of it all is just too cumbersome. The principles would be
ideal to have, but we can't make it work practically.

> 
> ~Stephen
> 
> 
> ___
> Discuss mailing list
> Discuss@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/discuss
> 

-- 
Aaron Wolf Snowdrift.coop <https://snowdrift.coop>
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss


Re: [Discuss] Fwd: What makes a team member?

2015-10-19 Thread Aaron Wolf


On 10/19/2015 11:05 AM, Jonathan Roberts wrote:
> Aaron, what are your thoughts about that?
> 

From here on, try to remember reply in context at the *bottom* of an
email / below the thing in context. It's much easier to follow that way.

Anyway, I think that it's okay to say that employees don't *have* to be
co-op members, and to be they must be patrons just like everyone else.
Or we could require it, but still have them be patrons.

> On Mon, Oct 19, 2015 at 11:04 AM, Jonathan Roberts
> <robertsthebr...@gmail.com <mailto:robertsthebr...@gmail.com>> wrote:
> 
> Brian,
> 
> Your first comment makes a lot of sense. I think that option is
> definitely off the table.
> 
> Paying a member fee is an interesting thought. I guess I hadn't
> considered that. I have been mostly thinking that it makes sense to
> give full time staff, payed or not, special representation on the
> board. In other words, I'm not sure I want a possibility for someone
> to be able to just "buy in" to that class, whatever we call it.
> 
> On Mon, Oct 19, 2015 at 10:33 AM, Bryan Richter <b...@chreekat.net
> <mailto:b...@chreekat.net>> wrote:
> 
> On Sat, Oct 17, 2015 at 10:09:22PM -0700, Aaron Wolf wrote:
> >
> > The question is: How do we determine who gets to count enough as a 
> team
> > member of Snowdrift and thus get to vote in that member class in the
> > co-op? The same question also must be answered for counting as a 
> member
> > of other project teams too.
> 
> I assume this idea has floated around before, but to be
> explicit, what
> of the notion of paying a nominal fee to become a member? That's the
> route taken by all the co-ops I've been a part of (Davis Food Coop,
> REI, etc.)
> 
> ___
> Discuss mailing list
> Discuss@lists.snowdrift.coop <mailto: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
> 

-- 
Aaron Wolf Snowdrift.coop <https://snowdrift.coop>
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss


Re: [Discuss] Flagging comments in the forum

2015-10-19 Thread Aaron Wolf
tion can be.

> I have a couple ideas. First, to just have a flag button, but not the
> option to check various offenses that are stated in accusatory language.
> Second, there could be just one button that says something like "I feel
> uncomfortable with this" and then the space to specify. I would
> especially like this option if there was a "this friend speaks my mind"
> button next to it that was equally prominent.
> 

Yes, we want to also include friendly things to express agreement and
thanks. I think our goal is to do that with tags, although we could have
some separate dedicated things. Those two are the main items:
"agreement" and "thanks".


> 
> ___
> Discuss mailing list
> Discuss@lists.snowdrift.coop
> https://lists.snowdrift.coop/mailman/listinfo/discuss
> 

-- 
Aaron Wolf Snowdrift.coop <https://snowdrift.coop>
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss


Re: [Discuss] Fwd: What makes a team member?

2015-10-17 Thread Aaron Wolf
y vote would be against changing the project
> user designations.

So, in the end, your points aren't entirely off-topic, they are very
relevant. We want to have the same public presentation of who is on a
project team as the legal specification of who gets to vote in the co-op
as part of the project class. At some level, it makes sense to say
"projects decide however they like who is formally part of their teams"
but we don't want a situation in which a project can artificially pack
the project class with people who support them just by claiming a bunch
of people as team members when they really aren't. But that may be a
worry that never materializes…

In the end, we should provide *some* specification to projects about
what qualifications a person should meet to be considered a formal part
of a project's team, and that same qualification might apply to the
Snowdrift team itself, or we could possibly have a more specific
qualification fo us…

> 
> On Sat, Oct 17, 2015 at 3:45 PM, Jonathan Roberts
> <robertsthebr...@gmail.com <mailto:robertsthebr...@gmail.com>> wrote:
> 
> Hey all,
> 
> I've been trying to solve the problem of what makes a "snowdrift
> project team member?" Snowdrift project team members elect a special
> representative on the board of directors, and it is assumed that
> they are tied in some way to the work of the co-op, but it's unclear
> what qualifications this group of people has, how their roles should
> be organized, what expectations should be put on them and who has
> the authority to ad them to that class.
> 
> I propose that instead of one class of "team members" that we have
> "employees" and "contributors." The "employees" would be hired and
> overseen by the general manager and would elect a special board
> representative. The "contributors" could be a much more open list;
> it could give credit to anyone who's helped out, list their contact
> info, and indicate whether they are still actively working on
> anything and what it is. There is a question in this framework of
> whether this class should also have a special board representative.
> I would say no, except that I think it is important that there be a
> designated advocate for anyone who thinks they should be getting
> payed for the work they're doing.
> 
> The biggest downside to this system I see is that we don't know,
> especially starting out, if we're going to have any money to pay
> people, even if they are indispensable to the ongoing functioning of
> snowdrift. One solution to this would be to let the GM include
> "unpayed staff" in the class at their discretion. We could also have
> it be a job qualification for any potential employee that they be
> listed as "active" on the "contributors" list, which could be
> governed by an algorithm that measures a base level of activity on
> the site.
> 
> Thoughts?
> 
> -Jon
> 
> 
> ___
> Discuss mailing list
> Discuss@lists.snowdrift.coop <mailto: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
> 

-- 
Aaron Wolf Snowdrift.coop <https://snowdrift.coop>
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss


Re: [Discuss] Slogan proposal: "Free the Commons!"

2015-10-01 Thread Aaron Wolf


On 09/30/2015 07:52 PM, Stephen Michel wrote:
> What if we simply removed the punctuation entirely?
> 

Certainly when folks talked about not using an exclamation mark, nobody
thought we'd replace it with a period. It's either "Free the Commons!"
or just "Free the Commons"


> Of course we'd add back in the appropriate punctuation where it's needed
> but for a place like directly under our name on the home page, I'm not
> sure it's needed.
> 
> ~Stephen
> 
> On Wed, Sep 30, 2015 at 5:56 PM, mray <m...@mray.de> wrote:
>> On 30.09.2015 20:30, Bryan Richter wrote:
>>
>> On Mon, Sep 28, 2015 at 10:08:18PM -0700, Aaron Wolf wrote:
>>
>> Per discussion recently, we worked through a lot of options
>> for slogans. It seem people with various critical views all
>> accept the value of the simple: Free the Commons! 
>>
>> Is the exclamation point part of the slogan? I like it better
>> without. "Free the Commons". 
>>
>> I think without exclamation marks is better, too.
>> ___ Discuss mailing list
>> Discuss@lists.snowdrift.coop <mailto: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
> 

-- 
Aaron Wolf Snowdrift.coop <https://snowdrift.coop>
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss


[Discuss] Slogan proposal: "Free the Commons!"

2015-09-28 Thread Aaron Wolf
Per discussion recently, we worked through a lot of options for slogans.
It seem people with various critical views all accept the value of the
simple: Free the Commons!

That call to action / mission is vague enough to not pigeon-hole us,
broad enough to be encompassing, poignant enough to be focused, short
and simple enough to be memorable, and it fits both our actual
operations, our FLO-focus, *and* the snowdrift metaphor well enough.

I propose we just go with it. We can still use the current "clearing the
path" slogan in some places informally.

Any objections to "Free the Commons!" as the final slogan?

I think it will be easy to then build writings / presentation that draws
upon this new succinct slogan.

Snowdrift.coop — Free the Commons!

-- 
Aaron Wolf Snowdrift.coop <https://snowdrift.coop>
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss


Re: [Discuss] Proposal: Simplified Defunding Mechanism

2015-09-23 Thread Aaron Wolf
Hi Stephen,

We're all on the same page already!

On 09/22/2015 11:23 PM, Stephen Michel wrote:
> _This email has two things:_
> 
> 1. Statement of our goals relating to the defunding mechanism, so we
> have an agreed-upon base to have a discussion from.
> 2. Proposal for simplified mechanism to accomplish those goals.
> 
> *1. Goals of a defunding mechanism:*
> 
> - Encourage users to deposit more funds in their account.
> - Provide users with an easy way out (if I decide to leave the coop, it
> sucks to have money stuck in my account)
> - Should be easily understandable and intuitive.
> 

The idea of withdrawing your funds when you leave is actually likely to
be something we cannot legally support. If we actually go with the idea
that the funds we hold are in fact still your money, we will almost
surely be considered an illegal money transfer service.

Thus, we have tentatively concluded that we only have two options:

A. All funds are donated immediately when deposited, pledges count as
voting for which projects get the funds. (This really won't discourage
deposits that much. If people support FLO in general, then the idea that
they can't get back their $10 is not a big deal, they can still deposit
incrementally).

B. Charge in arrears (we don't hold funds at all, we just charge people
once donations reach a threshold that is worth making a charge). This
means if people leave, we either make final uncomfortably low charges or
lose some amount of cents that would have been their final donations but
they didn't add up to enough to be worthwhile.

Neither of these are awful, and they really are the only options.

Details: https://snowdrift.coop/p/snowdrift/w/en/transactions

> 
> *2. Proposed new mechanism*
> *
> *
> - An account can only have two states: /Active/ and /Inactive./
> - When an account's balance falls below the amount required to pay all
> of their outstanding pledges in full, it becomes /inactive./
> - Pledges are now in terms of /active/ patrons. (when an account becomes
> /inactive, /other patrons no longer match for it.)
> - Owners of inactive accounts have three options:
>   1. Lower their pledge amounts until balance > payout
>   2. Add more money so that balance > payout
>   3. "One-time donation:" Donate to each project, immediately, a
> percentage of the money remaining in the account, so that when
> everything is paid, the user has $0 left in the account. This does NOT
> make their account become active or cause others to sponsor their shares
> (their acct is still /inactive./
> /
> /
> Now we only need 3 notification options:
> Account Balance is low (next payout will cause account to become
> inactive) |  Not Required
> Account becomes inactive | Required
> Payout Occurs | Not Required
> 
> Thoughts?
> 

We're already on it! We already decided to drop the whole idea of
partially active accounts and "shares". Bryan has been working on
implementation of this simplified approach. My thought and proposal is
almost *exactly* yours with a couple minor differences.

When total funds < total pledges, my version is: if this situation gets
all the way to a pay time with no adjustments in funds or pledges, then
the system automatically does the split up among projects. And in my
view, we *still* count that patron for this last time, even though the
donations are less than their full pledge.

The notification details you mention are exactly the plan.

You can check with Bryan about the status of his updating all the code
to implement this new simplified approach.

Here's the discussion: (looks like we didn't think to make it a ticket
per se, although it was known to us that this is Bryan's priority work
to focus on implementing this)
https://snowdrift.coop/p/snowdrift/w/en/mechanism/c/3419

Cheers! Keep the ideas coming, you're clearly thinking well about the
issues we're facing and how to design this well.

Best,
Aaron

-- 
Aaron Wolf Snowdrift.coop <https://snowdrift.coop>
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss


Re: [Discuss] Agree on a Slogan

2015-09-20 Thread Aaron Wolf
t to image of shoveling
snow, primarily because shoveling doesn't look like my image of "funding"…

So that leads me to some new brainstormed ideas…

"Help free the commons" — by whatever means we can, funding, work etc.
and *this* use of free as a *verb* has less confusion compared to free
as an adjective. This slogan is clean, clear, short, and fits both the
mission and the metaphor and image of shoveling the snow.

I just ran this by my wife, and she thinks this is best, so despite what
I wrote above, I think this is the best balance of meaningful,
appropriate, and not to jargony or pigeon-holing, and focusing the end
goal, not the means.

My vote now:  ***Help Free the Commons***

It implies that there is an *ostensible* commons but it is locked down
or inaccessible, covered in / blocked by snow / by proprietary
restrictions… we're going to free it together! HELP FREE THE COMMONS!


>> On Sun, Sep 20, 2015 at 12:29 PM, Aaron Wolf <aa...@snowdrift.coop>
>> wrote:
>>>
>>>
>>> On 09/20/2015 03:34 AM, mray wrote:
>>>> On 19.09.2015 21:10, Aaron Wolf wrote:
>>>>>
>>>>>> @"we":
>>>>>> "we" might be less inclusive than "together", but my point was
>> that it
>>>>>> addresses the human factor at all. (unlike "funding free
>> culture").
>>>>>> "we" is almost as important as the financial and freedom parts of
>> us.
>>>>>> "together" overreaches in that aspect in my opinion.
>>>>>> Let's face it: We are a closed club! We ask people to get on
>> board, open
>>>>>> up an account and trust their money with us. Our whole point is to
>>>>>> persuade people to join the in-group. Not drawing a line makes
>> that hard.
>>>>>> "we" is also short.
>>>>>>
>>>>>
>>>>> Although subtle, the ".coop" part of the name already includes the
>>>>> community aspect. Aesthetically, I like "funding" better than "we
>> fund",
>>>>> and the "ing" part emphasizes the ongoing aspect of things. I don't
>> feel
>>>>> strongly here though.
>>>>
>>>> The reason I value the "we" so strongly is because we need to make
>> clear
>>>> that snowdrift is something to be part of. "funding" alone makes it
>>>> remain unclear how the funding is done, but this is the *VERY*
>> essence
>>>> of our cause, it is "WE" who are funding this. not some snowdrift
>> entity.
>>>> along with "we fund" any appeal like "join us" makes so much more
>> sense,
>>>> it just fits way better.
>>>> aesthetically i don't care about either form that much.
>>>> "We fund" is more dynamic than "funding" I think, though.
>>>>
>>>
>>> I'm not sure about the dynamicness of "we fund" over "funding". I
>> really
>>> like the "ing", however, I agree about the collective / join us
>> issue.
>>>
>>> I wish it wasn't as long, but the feeling of togetherness is better
>>> spelled out. Ignoring length, "Working together to fund the digital
>>> commons" is the best way to completely get all the meaning. Another
>>> would be "collective funding of the digital commons" or "social
>> funding
>>> for the digital commons" or "coming together to fund the digital
>>> commons" or, how about: "join us in funding the digital commons!" or
>>> shorter version of that, "fund the digital commons with us!" or, I
>> like
>>> this best of my little brainstorm here: "help us fund the digital
>>> commons!" variations of that: "help fund the digital commons" or
>> "let's
>>> fund the digital commons" …
>>>
>>> I'm not opposed to "we" entirely, but I would like to get feedback
>> from
>>> others and see what others think of variations like I just posted.
>>>
>>>>
>>>>> ...
>>>>
>>>>>
>>>>> Let me be completely clear: the *only* reason I think it's okay at
>> all
>>>>> to consider a slogan that just says "free" but doesn't include
>> "open" is
>>>>> because we actually *want* projects on Snowdrift.coop to be
>> accessible
>>>>> at no-charge, 

Re: [Discuss] Agree on a Slogan

2015-09-17 Thread Aaron Wolf
Copying my reply from the design list (this discussion does belong on
the general discuss list)

On 09/16/2015 03:54 AM, mray wrote:
> Hello everybody,
>
>
> It is time to have a fruitful discussion about our slogan, we don't have
> one - but we should. My current mock-ups just use "FUNDING A FREE
> CULTURE" but that isn't anything that has been decided at all.
> We are about to create promotional resources and eventually I'd like to
> make use of a slogan. We need to settle this soon.
>
> The properties I seek in a slogan are:
> * brevity
> * concision
> * simplicity
> * clarity
>
> Concerning what the slogan could convey have a look at our mission:
>   https://snowdrift.coop/p/snowdrift/w/en/mission
> or the slogan page:
>   https://snowdrift.coop/p/snowdrift/w/en/slogan
>
> So here is my candidate:
>
>
> "WE FUND FREE CULTURE."
>
> WE   indicates that it is about people (many!), maybe including you
> FUND covers our financial angle
> FREE is the best compressed version of Free/Libre/Open
> CULTURE  represents the scope of different content we support
>
>
> Thoughts? Comments? Alternatives?
>

Obviously, it should be referenced that the current slogan on the site is:

"clearing the path to a Free/Libre/Open world"

The "clear the path" indicates our snowdrift metaphor (otherwise, with
no cue at all, it's far too easy for people to think 'snowball' and
think the snow metaphor is about how all the little donations add up,
instead of the desired metaphor of a blocked path). This version of the
slogan is predicated on a position that there exists no acceptable
truncation of "free/libre/open".

Why "free" even in "free culture" is a problem: Free is 95% of the time
associated with price, whether we like it or not. In fact, there's a
whole initiative in Portland, OR where I live to fight back against
"free culture" — that exact phrase. It's headed by musicians who are
trying to push back against the trend of people downloading music at no
charge (which we support, but we want artists funded) and *also*
(importantly) against the trend of bars getting live musicians to play
for zero pay just for "exposure" and such. In other words, to them "free
culture" is the whole trend of people thinking they can get everything
at no charge. Now, their whole initiative is misguided, but I mention it
for reference.

Obviously, "funding a free culture" makes it clear that we *aren't*
working against artists being paid. But still.

"culture" on its own definitely makes a lot of people thing this is
about art and not about science, software, or technology. Of course, we
have a strong software audience, so having a lot of software present, we
will be clearly about software, so emphasizing the cultural side in the
slogan does help offset that.

I think if there's one word to be the best truncation it's actually
"open" except that is a no-go because (A) tons of open-washing makes it
almost meaningless today, and (B) this would draw the ire of the FSF
folks who oppose the replacement of "free" with "open".

In various contexts, such as "clearing the path to a free world", the
term "free" sounds jingoistic, as "the free world" is used to mean
America / U.S. versus the Soviety Union etc.

Although "creative commons" is taken, various forms of statements around
the term "commons" or maybe "public goods" make sense. It is a totally
accurate way to describe us to say "we fund the digital commons" or
something of that ilk.

Please, others on this list, perspective is useful. Please share your
thoughts.

Best,
Aaron

-- 
Aaron Wolf Snowdrift.coop <https://snowdrift.coop>
___
Design mailing list
des...@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/design

-- 
Aaron Wolf Snowdrift.coop <https://snowdrift.coop>
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss


Re: [Discuss] Agree on a Slogan

2015-09-17 Thread Aaron Wolf


On 09/17/2015 09:55 AM, Bryan Richter wrote:
> On Wed, Sep 16, 2015 at 06:02:52PM -0600, Peter Harpending wrote:
>> On Wed, Sep 16, 2015 at 09:50:13PM +0200, mray wrote:
>>> Hello everybody,
>>>
>>> So here is my candidate:
>>>
>>>
>>> "WE FUND FREE CULTURE."
>>>
>>> WE   indicates that it is about people (many!), maybe including you
>>> FUND covers our financial angle
>>> FREE is the best compressed version of Free/Libre/Open
>>> CULTURE  represents the scope of different content we support
>>>
>>
>> The slogan in the IRC channel's /topic is "Clearing the path to a
>> free/libre/open world" or some such. I thought that was the slogan. It's
>> a good slogan. Perhaps I'm misunderstanding what a slogan is.
> 
> It's true: We *do* have a slogan, and arguments to change it must be
> heard.
> 
> Here are some other thoughts of mine:
> 
> In Aaron's response on the design list, he seems to imply that "open"
> is dead to us as a word to describe the kinds of works we want to
> support. I reject that claim. We don't *have* to use it, but I believe
> we *can* use it. Just because there is a thing called "open washing",
> and just because some close-minded people at an otherwise
> freedom-favoring organization have declared it anathema, doesn't mean
> it is now a meaningless word. If we want to give up every word that
> somebody makes a concerted effort to pervert, soon our language will
> consist of nothing but "buy now" and "Coke". I don't want the o-word
> to become like the n-word.
> 
> On that note, (again referring to Aaron's other email), the fact that
> some dastardly folks have decided to pervert the term "free culture"
> to mean something that is absolutely nothing like its current meaning,
> doesn't mean we have to play along. Free culture, in my opinion, is
> the English phrase where "free" has the strongest connotation with
> "libre". Culture is already free-as-in-beer. I won't be bullied or
> brainwashed into thinking it is anything otherwise.
> 
> Regarding Robert's suggestion: putting aside the question of
> discarding our existing slogan, I would suggest one tweak. "We" does
> not, in fact, suggest to me that it is "about peaple (many!), maybe
> including [me]". It instead suggests an exclusive "we". I think the
> following has a more inclusive feel: "Funding free culture, together".
> 
> That's all I got. I'm interested to hear more thoughts.
> 

I agree with "open" as an acceptable term, particularly in reference to
the strongest (and totally aligned with us and one of our accepted
definitions for projects) "Open Definition" http://opendefinition.org/od/

Furthermore, although we've gone with FLO overall and I really want
consistency in our messaging, "Free & Open" or "Free and Open" is
something that I think has strong merit in various cases.

I agree *completely* with the "together" versus the "we" issue. "We
fund…" definitely sounds like "we, the Snowdrift.coop folks" in a way
that does not at all come across as inclusive. It's comparable to a
restaurant saying "we serve the finest wine" or whatever.

FWIW, the evolution of the current slogan was:

"Working together to clear the obstacles"
"Working together to clear the path"
"Clearing the path to a free, libre, open world"
"Clearing the path to a Free/Libre/Open world"

I remain pretty strongly in favor of keeping the current slogan, but
would accept removing "libre" if it were insisted (but don't favor
that), and I'm perfectly fine with any alternatives to the punctuation,
including return to commas or using bullets or hyphens.

-- 
Aaron Wolf Snowdrift.coop <https://snowdrift.coop>
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss


[Discuss] Community engagement with Snowdrift.coop, mailing lists, forums…

2015-08-09 Thread Aaron Wolf
.

All the best,
Aaron

-- 
Aaron Wolf Snowdrift.coop https://snowdrift.coop
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss


Re: [Discuss] payment frequency

2015-07-13 Thread Aaron Wolf
So, regarding the frequency:

We can indeed vary the frequency of payments for both more frequent and
less frequent if, as we continue testing, it clearly seems the right
thing to do. We could also offer preference for users to increase or
decrease their support by changing frequency unilaterally (not changing
anyone else). I'm not opposed in principle.

As for the proposal of daily, I don't support that. Monthly is more
familiar and common. I suspect Peter is right that many would actually
feel less good about daily donation. And, most significantly, I think
monthly is a good balance for *accountability* which is a core aspect of
our design. Even a week is too short, I think, to fairly evaluate the
quality of a project's work. A month is a good amount of time where
people can expect to see reasonable progress and then consider whether
to pledge more or less.

Again, I think we can tweak this aspect, but I see monthly as clearly
the best MVP starting point.

Now, regarding the monetary buffer concept… that is the most obvious
and best way to work, period. We proposed initially that this would be
the way we would handle funds. It's sort of like escrow. However, we
have not yet confirmed with accountants or tax attorneys that such a
monetary buffer approach is legally acceptable. We have reasons to be
concerned because we absolutely do not want to be a money transfer
service. See the details at
https://snowdrift.coop/p/snowdrift/w/en/transactions and the links from
that. Figuring out this issue is one of our high-priority items, but
we're juggling many different priorities still.

Thanks everyone for being engaged and sharing these thoughts!

-- 
Aaron Wolf Snowdrift.coop https://snowdrift.coop
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss


Re: [Discuss] anonymity and payment

2015-07-12 Thread Aaron Wolf


On 07/12/2015 02:38 AM, mray wrote:
 Listening to a RMS talk reminded me that anonymity in payment processes
 really matters. I think snowdrift.coop should offer anonymous payment,
 too. I'm totally ignorant on the technical side of it in general, but
 also concerning our own plans. Nevertheless there is a promising project
 that seems to address that issue:
 
 http://taler.net
 
 
 What are other opinions on that?
 
 
 Cheers,
 Robert
 


RMS personally brought this up to us when we first talked to him about
Snowdrift.coop. So, it's in the list of stuff we want to do in
principle. Taler is listed already at
https://snowdrift.coop/p/snowdrift/w/en/payment-services

In practice, the legal and practical issues are unclear. Probably we can
get away with legally accepting anonymous donations but not anonymous
payouts. Practically, until Taler or something is really working, I'm
not sure what we can really do. But we're aware of the issue. We may not
have all our ideals working from the beginning of course.

-- 
Aaron Wolf Snowdrift.coop https://snowdrift.coop
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss