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 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
for use by normal users.  If there are others, we'll want to try to figure
out SSO for them as well.  We may also want to figure out some site
integration testing for the various subsites to ensure we don't
accidentally break something down the road.

Any thoughts on this?

- Jason (JazzyEagle)

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

Aaron wrote:

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

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

We want people to say "I'm in" for the vision and stay involved and see
where things 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.

This is my biggest fear about my proposal. I think my proposal is simpler /
easier to scale, but at the expense of being more similar to existing
systems and prone to their existing flaws.

Discuss mailing list
Discuss mailing list

Reply via email to