Raising engagement
46 views
Skip to first unread message
Hynek Schlawack
Jul 30, 2019, 4:38:21 AM7/30/19
to pylons-...@googlegroups.com
Hi everyone,
I don’t think I’m breaking any news when I say that the development in the Pyramid ecosystem has gone a bit down and it’s especially exemplified by amount of SQLAlchemy warnings I have to silence in my projects that seem to be unlikely to be fixed (<https://twitter.com/laurencerowe/status/1156111287631273985>).
In the worst case this means that we’ll end up without SQLAlchemy for our documented workflows soon. There also was the problem that the i18n documentation was an incoherent mixture of old and new tools but that’s been a while so I’m not sure if it’s still true. Venusian is triggering deprecation warnings too btw.
The problem of course is that the current maintenance burden is carried by far too few people (thank you so much Michael, Bert, and Steve!).
***
One thing we could do is to find a way to stop using/advertising packages that have to be maintained by use and push for those that we share with Flask that is doing much better. WTForms instead of deform comes to mind, Jinja2 instead of Chameleon, and waitress might also not be worth the time Bert is putting into it (unless he’s enjoying it :)). Basically cut our losses and focus the remaining energy where it’s most worth it. I realize this is not a popular proposition.
***
My main point is a different though.
I have tried to look at the projects that are screaming for attention and found them very daunting and alien so I suspect I’m not the only one who looked at it and gave up.
I hope at least some of you might have seen my PyCon US talk this year where I talk about friction in contribution: https://hynek.me/talks/python-foss/
My offer for you would be choose select projects that are essential to write awesome Pyramid apps and pull them into 2019 whether they like it or not. I’m not gonna start though unless we can agree on it happening and how – turns out my copious free time is everything but. 😬 But I do care about Pyramid and I want it to stay strong.
***
Finally, there’s also the fact that Pyramid is used by PyPI/warehouse so I suspect that it should be possible to ask the PSF for money to close the biggest current gaps? Any freelancers maybe?
***
I know there’s absolutely nothing I can do from people starting discussing my motivation (paragraph 1) and “dead batteries” (paragraph 2) vs my offer (paragraph 3) but I’d still love to get a somewhat focused discussion. Maybe split your replies?
Cheers,
—h
I don’t think I’m breaking any news when I say that the development in the Pyramid ecosystem has gone a bit down and it’s especially exemplified by amount of SQLAlchemy warnings I have to silence in my projects that seem to be unlikely to be fixed (<https://twitter.com/laurencerowe/status/1156111287631273985>).
In the worst case this means that we’ll end up without SQLAlchemy for our documented workflows soon. There also was the problem that the i18n documentation was an incoherent mixture of old and new tools but that’s been a while so I’m not sure if it’s still true. Venusian is triggering deprecation warnings too btw.
The problem of course is that the current maintenance burden is carried by far too few people (thank you so much Michael, Bert, and Steve!).
***
One thing we could do is to find a way to stop using/advertising packages that have to be maintained by use and push for those that we share with Flask that is doing much better. WTForms instead of deform comes to mind, Jinja2 instead of Chameleon, and waitress might also not be worth the time Bert is putting into it (unless he’s enjoying it :)). Basically cut our losses and focus the remaining energy where it’s most worth it. I realize this is not a popular proposition.
***
My main point is a different though.
I have tried to look at the projects that are screaming for attention and found them very daunting and alien so I suspect I’m not the only one who looked at it and gave up.
I hope at least some of you might have seen my PyCon US talk this year where I talk about friction in contribution: https://hynek.me/talks/python-foss/
My offer for you would be choose select projects that are essential to write awesome Pyramid apps and pull them into 2019 whether they like it or not. I’m not gonna start though unless we can agree on it happening and how – turns out my copious free time is everything but. 😬 But I do care about Pyramid and I want it to stay strong.
***
Finally, there’s also the fact that Pyramid is used by PyPI/warehouse so I suspect that it should be possible to ask the PSF for money to close the biggest current gaps? Any freelancers maybe?
***
I know there’s absolutely nothing I can do from people starting discussing my motivation (paragraph 1) and “dead batteries” (paragraph 2) vs my offer (paragraph 3) but I’d still love to get a somewhat focused discussion. Maybe split your replies?
Cheers,
—h
Steve Piercy
Jul 30, 2019, 10:45:04 AM7/30/19
to pylons-...@googlegroups.com
First to clarify, neither SQLAlchemy nor zope.sqlalchemy are
Pylons projects, although they may be dependencies for using SQL
databases as a datasource in Pyramid.
https://github.com/sqlalchemy/sqlalchemy
https://github.com/zopefoundation/zope.sqlalchemy
We Pylons maintainers agree with much of what you state. We
have identified the top points of friction for contributors.
* Signing a CLA
* Licensing
We're actively working through how to improve these items,
including relicensing and how to do so. We've gone through a
couple of iterations with third parties and the Plone
Foundation, and are currently in discussion with the Python
Software Foundation. If you want details of this process (it's
boring and tedious), please let us know.
The process includes the ability to receive and disburse funds,
something that previously went through Gratipay where an
individual incurred tax liability. We are not going to do that
again. We have not applied for grants because the Pylons
Project is not a legal entity that can receive funds; it's made
of people. Agendaless is an option, but it would not be a
taxable event. The PSF offers a non-profit tax-deductible
option which is under consideration.
As part of the organizational process, we looked at the long
list of Pylons projects under our GitHub user. We've classified
them as core, community, and tomb (unmaintained). We're focused
on core (https://pylonsproject.org/projects.html).
GitHub has adopted a lot of features that we want to implement,
but lack the time. Those features include all the things that
can be placed in `.github/`. I would welcome any issues or PRs
that add missing files, either per repo or preferably globally
under the Pylons GitHub user. It would save a lot of
reinventing the wheel.
We have done a lot of work in Pyramid to reduce friction. That
includes documentation, cookiecutter, pytest, tox, Black,
flake8, isort, and Travis-CI, Appveyor, and RTD. There is
active work on the Pyramid 2.0 release (https://github.com/Pylons/pyramid/milestone/5).
Pyramid has three open issues on i18n
(https://github.com/Pylons/pyramid/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+i18n),
all of which are purely documentation. But again it's a matter
of time of knowledgeable people to share their best practices
and documenting them. I would welcome someone mentoring me on
how to do i18n properly, and I would document the process.
Pyramid does not care which templating library you use, there is
no longer a default, and offers add-ons with bindings for Mako,
Jinja2, and Chameleon.
Pyramid does not care which form library you use, but just like
templates offers bindings for form libraries. The growing trend
is away from server-side form rendering libraries like Deform
and WTForms to front-end JavaScript libraries that call an API,
all of which Pyramid supports.
Finally if you have specific issues that we can address, please
let us know.
--steve
On 7/30/19 at 10:38 AM, h...@ox.cx (Hynek Schlawack) pronounced:
------------------------
Steve Piercy, Eugene, OR
Pylons projects, although they may be dependencies for using SQL
databases as a datasource in Pyramid.
https://github.com/sqlalchemy/sqlalchemy
https://github.com/zopefoundation/zope.sqlalchemy
We Pylons maintainers agree with much of what you state. We
have identified the top points of friction for contributors.
* Signing a CLA
* Licensing
We're actively working through how to improve these items,
including relicensing and how to do so. We've gone through a
couple of iterations with third parties and the Plone
Foundation, and are currently in discussion with the Python
Software Foundation. If you want details of this process (it's
boring and tedious), please let us know.
The process includes the ability to receive and disburse funds,
something that previously went through Gratipay where an
individual incurred tax liability. We are not going to do that
again. We have not applied for grants because the Pylons
Project is not a legal entity that can receive funds; it's made
of people. Agendaless is an option, but it would not be a
taxable event. The PSF offers a non-profit tax-deductible
option which is under consideration.
As part of the organizational process, we looked at the long
list of Pylons projects under our GitHub user. We've classified
them as core, community, and tomb (unmaintained). We're focused
on core (https://pylonsproject.org/projects.html).
GitHub has adopted a lot of features that we want to implement,
but lack the time. Those features include all the things that
can be placed in `.github/`. I would welcome any issues or PRs
that add missing files, either per repo or preferably globally
under the Pylons GitHub user. It would save a lot of
reinventing the wheel.
We have done a lot of work in Pyramid to reduce friction. That
includes documentation, cookiecutter, pytest, tox, Black,
flake8, isort, and Travis-CI, Appveyor, and RTD. There is
active work on the Pyramid 2.0 release (https://github.com/Pylons/pyramid/milestone/5).
Pyramid has three open issues on i18n
(https://github.com/Pylons/pyramid/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+i18n),
all of which are purely documentation. But again it's a matter
of time of knowledgeable people to share their best practices
and documenting them. I would welcome someone mentoring me on
how to do i18n properly, and I would document the process.
Pyramid does not care which templating library you use, there is
no longer a default, and offers add-ons with bindings for Mako,
Jinja2, and Chameleon.
Pyramid does not care which form library you use, but just like
templates offers bindings for form libraries. The growing trend
is away from server-side form rendering libraries like Deform
and WTForms to front-end JavaScript libraries that call an API,
all of which Pyramid supports.
Finally if you have specific issues that we can address, please
let us know.
--steve
On 7/30/19 at 10:38 AM, h...@ox.cx (Hynek Schlawack) pronounced:
Steve Piercy, Eugene, OR
Kay Mccormick
Jul 30, 2019, 3:28:27 PM7/30/19
to pylons-...@googlegroups.com
I'm happy to assist - I will try to find some open issues to tackle.
--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/r480Ps-10126i-42F99BA844B545CF9DE076A5B5033421%40Steves-iMac.local.
Reply all
Reply to author
Forward
0 new messages