Development Setup Rework

[Adam Hernandez]

Jochen, 

I'm starting on reworking the development setup process, based on the outdated wiki information. The one thing I need specifically is the currently supported Python, MySQL, and Elasticsearch versions so I can make sure I'm pinning to the correct ones. My goal is to make spinning up a dev environment quick and easy so we can hopefully get more contributors. And just FYI I'm in between jobs at the moment so I've got plenty of time to help out with the project LOL. 

Thanks, 

Adam

[Jochen G.]

I am not sure if we want to make our specific production setup that public.

But we can surely define a standard dev environment.

requires-python = ">=3.13,<3.14"
"elasticsearch>7.0,<8.0",

I do dev with MariaDB actually, but Mysql >= 8.0

Jochen

Am 31.07.26 um 23:05 schrieb Adam Hernandez:

> --
> You received this message because you are subscribed to the Google
> Groups "gcd-tech" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to gcd-tech+u...@googlegroups.com <mailto:gcd-
> tech+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/gcd-
> tech/9da7cb12-b86f-47eb-a79d-63ef08f6c008n%40googlegroups.com <https://
> groups.google.com/d/msgid/gcd-tech/9da7cb12-b86f-47eb-
> a79d-63ef08f6c008n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Adam Hernandez]

Got it. I'll pin the version that way. 

Thanks!

Adam

[Jochen G.]

Adam,

in view of the API, one thing to consider is different ways of
authentication, e.g. token based.

Also, we might want/need to consider different access limits for
authenticated vs. donating users. Assuming we can differentiate in view
of our non-profit status.

Since these are related to the API, might be something for you to look into.

Jochen

Am 31.07.26 um 23:05 schrieb Adam Hernandez:

[Brian Pepple]

On 8/2/26 9:19 AM, 'Jochen G.' via gcd-tech wrote:
> in view of the API, one thing to consider is different ways of
> authentication, e.g. token based.
>
> Also, we might want/need to consider different access limits for
> authenticated vs. donating users. Assuming we can differentiate in
> view of our non-profit status.
>
> Since these are related to the API, might be something for you to look
> into.

Been meaning to mention these items to you, since I recently implemented
them at Metron and it might be worth offering at GCD.

I'm not sure what you guys use to handle your donations, but you might
want to look into OpenCollective [1], since they can handle non-profits
and provide information to your users/donors on how their donations are
spent. More importantly, they offer an API which would let you retrieve
user donation info and use that to offer a higher daily rate limit as a
perk for your donors. I wrote a blog post on the broad strokes of
supporter rate-limits, if you're curious [2].

I've also finally gotten around to implementing token-based
authentication, and announced [3] that we're sunsetting Basic
Authentication in 9-12 months — might be worth thinking about for GCD too.

Anyway, just thought I'd throw in my 2¢ since both projects have similar
tech issues.

1) https://opencollective.com/
2) https://metron-project.github.io/blog/supporter-rate-limits
3) https://metron-project.github.io/blog/token-authentication

Take care,
/B

--
Brian Pepple <bpe...@metron.cloud>

https://about.me/brian.pepple

[Adam Hernandez]

Brian, thanks for he insight. 

Jochen, I'll add this to the list of items for follow up post APIv2 release. 

Adam

[Donald Dale Milne]

    Currently our donations are handled by PayPal.  We are in the
process of closing an old, member-owned account and transferring all
donations to a corporate-owned account.  In fact, I will be sending out
a 2nd notice to our donors this week.  At this time, we do not perform
any tasks that are dependent on donor status: all volunteers are treated
the same.  We have not reviewed a two-tiered system with our accountant,
but considering some problems we had previously, it is possible that
making certain actions dependent on donor status might be considered
selling a service.  Thanks for the link to OpenCollective.  It may be a
service worth considering at some point.  I would be interested in
reading your blog post on supporter rate-limits if you send a link.

- Don Milne

[Brian Pepple]

On 8/2/26 6:07 PM, 'Donald Dale Milne' via gcd-tech wrote:

    Currently our donations are handled by PayPal.  We are in the process of closing an old, member-owned account and transferring all donations to a corporate-owned account.  In fact, I will be sending out a 2nd notice to our donors this week.  At this time, we do not perform any tasks that are dependent on donor status: all volunteers are treated the same.  We have not reviewed a two-tiered system with our accountant, but considering some problems we had previously, it is possible that making certain actions dependent on donor status might be considered selling a service.  Thanks for the link to OpenCollective.  It may be a service worth considering at some point.  I would be interested in reading your blog post on supporter rate-limits if you send a link. 

Makes sense re: closing out the old account and moving to a corporate-owned one for the donations. I also hear you on the two-tiered/"selling a service" concern. Even as a non-profit, I'd think there's a solid case this counts as mission-related income rather than "selling a service." But that's obviously a call for your accountant, not me.

My goals for the tiered rate limits system were:

• Offer a higher rate limit than our default. Surprisingly there have been a lot of comic shops making use of the API, and I've gotten a lot of requests wanting to pay to have a higher daily limit.
• Have an automated process. I didn't want this to be a manual process, and with the OpenCollective API, it's all handled with a simple hourly Django management command (provided the user's email matches at both sites).
• Help with the financial stability of the project.

Anyway, here's a link to the blog post I wrote: https://metron-project.github.io/blog/supporter-rate-limits

[Adam Hernandez]

An idea...instead of making the additional bandwidth based on donations, lets make it based on service to the organization. What if a user had to add or edit so many issues/series or upload so many covers in order to earn "bandwidth points" that give them better rate limits on a tiered system. This keeps in line with that fact that we're a service organization and doesn't require a financial transaction to get premium service. 

Thoughts?

Adam

[Brian Pepple]

On 8/2/26 11:37 PM, Adam Hernandez wrote:

An idea...instead of making the additional bandwidth based on donations, lets make it based on service to the organization. What if a user had to add or edit so many issues/series or upload so many covers in order to earn "bandwidth points" that give them better rate limits on a tiered system. This keeps in line with that fact that we're a service organization and doesn't require a financial transaction to get premium service. 

Thoughts?

I've thought about doing that, in addition to offering donors a higher rate limit, since not everyone is in a financial position to donate.

That said, offering it would require some real infrastructure and metric-gathering to support a gamification-style rate-limit feature — I'd need to define what actually counts as a "quality" contribution (to prevent someone gaming the system with junk edits or low-effort uploads just to farm points), plus build review/approval logic and track it per user. With the services OpenCollective offers, it was fairly trivial to add support for donor-based rate limits; building an equivalent contribution-based system is a bigger lift.

Also, for the most part, the majority of users who reach out wanting a higher rate limit are comic/sports card shops (online and physical) who don't have much interest — or time — in contributing to the site. So it's a fairly low priority, and I likely won't look into it seriously until next year.

Speaking of infrastructure priorities — one problem I'm actively trying to solve right now is how best to handle upcoming solicitations, since some publishers don't release cover images (with the final cover dressing) until about 2 weeks before publication. *Looks sternly in Marvel's direction*

[Donald Dale Milne]

    FYI, we do currently track one metric for indexing, "Index Measuring Points".  These are awarded for indexing work according to the rules at https://docs.comics.org/wiki/IMPs .

- Don Milne

--

You received this message because you are subscribed to the Google Groups "gcd-tech" group.

To unsubscribe from this group and stop receiving emails from it, send an email to gcd-tech+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/gcd-tech/aa7ac72a-abcd-4cc0-941a-28fe3278b9c3%40metron.cloud.