Hi, i was thinking with Chris Mcdonough about creating something like the plone collective: What's that ? That's may one be the most successful things in the plone community for me.
For those who are not aware of and don't want to open links, it consists in giving a "meta repository" where all community members are given read & write to all inner repo minor the "delete repo" thing. This "meta repository" is not synonym of quality neither the contrary. Focus is really on central community contribution. For core quality concerns, use what's in pyramid organization. The main goal is to centralize contributions.
- This allow a central place to push your addons or pyramid related software encouraging re-usability and inter contributions. - One of the biggest problems, I found nowadays with pyramid is the lack of consistence between packages. The "pyramid collective" may lead to improve this lack as developers/users will be more aware of the ecosystem and try to integrate things among others. - No contributor agreement required, welcome to everything without some written implication.
How ?
- We can create a git-hub organization inspired by the plone's collective one.. - To handle the read/write security problem, inspire ourselves from this script: http://pypi.python.org/pypi/github-collective.
How about existing packages ?
- We may need to make some evangelism to encourage people to migrate their add-ons from their private repos to the collective.
In organization terms speaking, we will need some staffers to handle the collective in pretty shape.
- Managing organization members. - Accepting pull requests from the "permissions.cfg" to create repos on the github organization. - Giving some sort of support.
On Thu, 2012-04-12 at 12:46 +0200, kiorky wrote: > Hi, i was thinking with Chris Mcdonough about creating something like > the plone collective: > What's that ? That's may one be the most successful things in the > plone community for me.
> For those who are not aware of and don't want to open links, it > consists in giving a "meta repository" where all community members are > given read & write to all inner repo minor the "delete repo" thing. > This "meta repository" is not synonym of quality neither the contrary. > Focus is really on central community contribution. > For core quality concerns, use what's in pyramid organization. > The main goal is to centralize contributions.
> - This allow a central place to push your addons or pyramid > related software encouraging re-usability and inter contributions. > - One of the biggest problems, I found nowadays with pyramid is > the lack of consistence between packages. > The "pyramid collective" may lead to improve this lack as > developers/users will be more aware of the ecosystem and try to > integrate things among others. > - No contributor agreement required, welcome to everything without > some written implication.
> How ?
> - We can create a git-hub organization inspired by the plone's > collective one.. > - To handle the read/write security problem, inspire ourselves > from this script: http://pypi.python.org/pypi/github-collective.
> How about existing packages ?
> - We may need to make some evangelism to encourage people to > migrate their add-ons from their private repos to the collective.
> In organization terms speaking, we will need some staffers to handle > the collective in pretty shape.
> - Managing organization members. > - Accepting pull requests from the "permissions.cfg" to create > repos on the github organization. > - Giving some sort of support.
I'm very +1 on this, it's a good idea; I can't currently take on the task of being in charge of it though.
We'd need a few somebodys to set such a thing up and manage it, promotes it, decide what goes in and what stays out, grants and revokes access, maintain something on pylonsproject.org that at least links to it, etc. Anybody want to do that?
On Thu, Apr 12, 2012 at 12:55 PM, Chris McDonough <chr...@plope.com> wrote: > On Thu, 2012-04-12 at 12:46 +0200, kiorky wrote: >> Hi, i was thinking with Chris Mcdonough about creating something like >> the plone collective: >> What's that ? That's may one be the most successful things in the >> plone community for me.
>> For those who are not aware of and don't want to open links, it >> consists in giving a "meta repository" where all community members are >> given read & write to all inner repo minor the "delete repo" thing. >> This "meta repository" is not synonym of quality neither the contrary. >> Focus is really on central community contribution. >> For core quality concerns, use what's in pyramid organization. >> The main goal is to centralize contributions.
>> - This allow a central place to push your addons or pyramid >> related software encouraging re-usability and inter contributions. >> - One of the biggest problems, I found nowadays with pyramid is >> the lack of consistence between packages. >> The "pyramid collective" may lead to improve this lack as >> developers/users will be more aware of the ecosystem and try to >> integrate things among others. >> - No contributor agreement required, welcome to everything without >> some written implication.
>> How ?
>> - We can create a git-hub organization inspired by the plone's >> collective one.. >> - To handle the read/write security problem, inspire ourselves >> from this script: http://pypi.python.org/pypi/github-collective.
>> How about existing packages ?
>> - We may need to make some evangelism to encourage people to >> migrate their add-ons from their private repos to the collective.
>> In organization terms speaking, we will need some staffers to handle >> the collective in pretty shape.
>> - Managing organization members. >> - Accepting pull requests from the "permissions.cfg" to create >> repos on the github organization. >> - Giving some sort of support.
> I'm very +1 on this, it's a good idea; I can't currently take on the > task of being in charge of it though.
+1. I'm sure that the collective is something that have helped Plone to be one of the major CMS of the last decade. And this can boost pyramid too. I'll be happy to move my pyramid's related projects to this organization.
> We'd need a few somebodys to set such a thing up and manage it, promotes > it, decide what goes in and what stays out, grants and revokes access, > maintain something on pylonsproject.org that at least links to it, etc. > Anybody want to do that?
> - C
> -- > You received this message because you are subscribed to the Google Groups "pylons-discuss" group. > To post to this group, send email to pylons-discuss@googlegroups.com. > To unsubscribe from this group, send email to pylons-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
As long as i'm not the only person, i agree to do some stuff on this purpose. The initial work won't be that much. - Create the gh organisation & teams, - Install the github-collective cron somewhere (where !?). - Write something in the documentation how to use the collective - Make another mail to make the thing official - Recruit & add volunteer staffers...
-- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF Pensez ŕ l’environnement. N’imprimez ce courriel que si vous en avez vraiment besoin.
> As long as i'm not the only person, i agree to do some stuff on this > purpose. > The initial work won't be that much. > - Create the gh organisation & teams, > - Install the github-collective cron somewhere (where !?). > - Write something in the documentation how to use the collective > - Make another mail to make the thing official > - Recruit & add volunteer staffers...
> -- > Cordialement, > KiOrKY > GPG Key FingerPrint: 0x1A1194B7681112AF > Pensez ŕ l’environnement. > N’imprimez ce courriel que si vous en avez vraiment besoin.
> -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To post to this group, send email to pylons-discuss@googlegroups.com. > To unsubscribe from this group, send email to > pylons-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/pylons-discuss?hl=en.
I don't want to discourage anyone from doing this, but my initial thought, at least, is that the Plone collective came from a place and a time where hosting your own code in public wasn't ridiculously easy the way it is now. Now anyone can host whatever they want on Github. Or Bitbucket, Sourceforge, Launchpad, etc.... From reading the thread I do so that beyond just a place to host there does seem to be a desire to have a sort of clearing house that is one place people can go to to see what's in the collective, which makes sense. But in this day and age, given the options to host and distribute, that could be as simple as a web page that acts as a registry for people's projects. Managing that might be a little bit easier and be just as good. Just a thought.
Giving a big group of people commit access to addon packages results in conflicts if intended commit was useful to everyone. Most simple example is breaking tests for sake of being lazy and adding functionality. It can be of course mostly avoided, but not prevented.
Having something like djangopackages.com + pypi classifier would achieve the same goal. Pull requests are also easy to make, I would propose rather to have a good read about preferred way of contributing to package maintainers.
Also managing permissions (or basically and configuration) for organisations on github in PITA.
Cheers, Domen
On Thu, Apr 12, 2012 at 2:23 PM, Chris Rossi <ch...@archimedeanco.com>wrote:
> I don't want to discourage anyone from doing this, but my initial thought, > at least, is that the Plone collective came from a place and a time where > hosting your own code in public wasn't ridiculously easy the way it is now. > Now anyone can host whatever they want on Github. Or Bitbucket, > Sourceforge, Launchpad, etc.... From reading the thread I do so that > beyond just a place to host there does seem to be a desire to have a sort > of clearing house that is one place people can go to to see what's in the > collective, which makes sense. But in this day and age, given the options > to host and distribute, that could be as simple as a web page that acts as > a registry for people's projects. Managing that might be a little bit > easier and be just as good. Just a thought.
> Chris
> -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To post to this group, send email to pylons-discuss@googlegroups.com. > To unsubscribe from this group, send email to > pylons-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/pylons-discuss?hl=en.
On Thu, Apr 12, 2012 at 7:41 AM, Domen Kožar <do...@dev.si> wrote: > Having something like djangopackages.com + pypi classifier would achieve the > same goal. Pull requests are also easy to make, I would propose rather to > have a good read about preferred way of contributing to package maintainers.
I'm much more +1 on maintaining and improving http://pyramid.opencomparison.org/ (djangopackages). I've also requested on catalog-sig a "Framework :: Pyramid" trove classifier. I think in the era of DVCS it doesn't make much sense to attempt to manage organizations and commit access rights. You and your maintainers own the project repo, other people can submit pull requests. What is more important is that the source repositories are easy to find, for which I think the opencomparison page does a good job. I think the opencomparison page needs much more visibility within the community.
> Giving a big group of people commit access to addon packages results > in conflicts if intended commit was useful to everyone. Most simple > example is breaking tests for sake of being lazy and adding > functionality. It can be of course mostly avoided, but not prevented.
IMHO, it worth the risk as we may loose some coherence between contributions by not having a common place to contribute. Many factors can just be avoided like maintainer hitted by a bus, or dictator, or diverging opinions. It's more easy to handle by just commiting stuff at the revert/reset risk.
> Having something like djangopackages.com <http://djangopackages.com> + > pypi classifier would achieve the same goal. Pull requests are also > easy to make, I would propose rather to have a good read about > preferred way of contributing to package maintainers.
> Also managing permissions (or basically and configuration) for > organisations on github in PITA.
> Cheers, Domen
> On Thu, Apr 12, 2012 at 2:23 PM, Chris Rossi <ch...@archimedeanco.com > <mailto:ch...@archimedeanco.com>> wrote:
> I don't want to discourage anyone from doing this, but my initial > thought, at least, is that the Plone collective came from a place > and a time where hosting your own code in public wasn't > ridiculously easy the way it is now. Now anyone can host whatever > they want on Github. Or Bitbucket, Sourceforge, Launchpad, > etc.... From reading the thread I do so that beyond just a place > to host there does seem to be a desire to have a sort of clearing > house that is one place people can go to to see what's in the > collective, which makes sense. But in this day and age, given the > options to host and distribute, that could be as simple as a web > page that acts as a registry for people's projects. Managing that > might be a little bit easier and be just as good. Just a thought.
> Chris
> -- > You received this message because you are subscribed to the Google > Groups "pylons-discuss" group. > To post to this group, send email to > pylons-discuss@googlegroups.com > <mailto:pylons-discuss@googlegroups.com>. > To unsubscribe from this group, send email to > pylons-discuss+unsubscribe@googlegroups.com > <mailto:pylons-discuss%2Bunsubscribe@googlegroups.com>. > For more options, visit this group at > http://groups.google.com/group/pylons-discuss?hl=en.
> -- > You received this message because you are subscribed to the Google > Groups "pylons-discuss" group. > To post to this group, send email to pylons-discuss@googlegroups.com. > To unsubscribe from this group, send email to > pylons-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/pylons-discuss?hl=en.
> On Thu, Apr 12, 2012 at 7:41 AM, Domen Kožar<do...@dev.si> wrote: >> Having something like djangopackages.com + pypi classifier would achieve the >> same goal. Pull requests are also easy to make, I would propose rather to >> have a good read about preferred way of contributing to package maintainers. > I'm much more +1 on maintaining and improving > http://pyramid.opencomparison.org/ (djangopackages). I've also > requested on catalog-sig a "Framework :: Pyramid" trove classifier. I > think in the era of DVCS it doesn't make much sense to attempt to > manage organizations and commit access rights.
For me it is now about managing rights, it is just to avoid packages deletion. In any case everyone get commit rights, so there are no real managment, just a deletion barrier. the djangopackages and the collective just complete themselves.
Its like http://plone.org/products and the collective, they complete themselves and are both neccesary.
> You and your > maintainers own the project repo, other people can submit pull > requests. What is more important is that the source repositories are > easy to find,
But not then really that simple to contribute. It is a 'less' open way in my opinion.
> for which I think the opencomparison page does a good > job. I think the opencomparison page needs much more visibility within > the community.
Yes, the links must be replicated to as many places we can.
On Apr 12, 2012, at 9:58 AM, Michael Merickel wrote:
> On Thu, Apr 12, 2012 at 7:41 AM, Domen Kožar <do...@dev.si> wrote: >> Having something like djangopackages.com + pypi classifier would achieve the >> same goal. Pull requests are also easy to make, I would propose rather to >> have a good read about preferred way of contributing to package maintainers.
> I'm much more +1 on maintaining and improving > http://pyramid.opencomparison.org/ (djangopackages). I've also > requested on catalog-sig a "Framework :: Pyramid" trove classifier. I > think in the era of DVCS it doesn't make much sense to attempt to > manage organizations and commit access rights. You and your > maintainers own the project repo, other people can submit pull > requests. What is more important is that the source repositories are > easy to find, for which I think the opencomparison page does a good > job. I think the opencomparison page needs much more visibility within > the community.
my initial impression is leaning this way as well, my concern with a central repo that everyone publishes towards is that you get a lot of lemons, and the system doesn't provide any way to newcomers to distinguish between the first-class, recommended approaches versus half-baked ideas that will get people into trouble. You'd then say, OK well someone needs to curate the collection of things - easier said than done. There's a lot of old recipes on the SQLAlchemy wiki I'd love to blow away, but , well one of my users went through all the trouble to write it and I don't want to upset him, and well OK maybe it's somewhat useful if not out of date, so it just stays up there, as a sort-of-not-quite-useful thing. Plus you need someone curating all these things in the first place. The repo starts looking like a stale graveyard for discarded ideas. For a project that is desperate to provide a consistent, simple story for newcomers (something I think Pyramid and SQLAlchemy share), these open ended repositories just add to the confusion, pushing up a large list of highly varied approaches into a flattened presentation.
> -- > You received this message because you are subscribed to the Google Groups "pylons-discuss" group. > To post to this group, send email to pylons-discuss@googlegroups.com. > To unsubscribe from this group, send email to pylons-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
On Thu, 2012-04-12 at 10:34 -0400, Michael Bayer wrote: > On Apr 12, 2012, at 9:58 AM, Michael Merickel wrote:
> > On Thu, Apr 12, 2012 at 7:41 AM, Domen Kožar <do...@dev.si> wrote: > >> Having something like djangopackages.com + pypi classifier would achieve the > >> same goal. Pull requests are also easy to make, I would propose rather to > >> have a good read about preferred way of contributing to package maintainers.
> > I'm much more +1 on maintaining and improving > > http://pyramid.opencomparison.org/ (djangopackages). I've also > > requested on catalog-sig a "Framework :: Pyramid" trove classifier. I > > think in the era of DVCS it doesn't make much sense to attempt to > > manage organizations and commit access rights. You and your > > maintainers own the project repo, other people can submit pull > > requests. What is more important is that the source repositories are > > easy to find, for which I think the opencomparison page does a good > > job. I think the opencomparison page needs much more visibility within > > the community.
> my initial impression is leaning this way as well, my concern with a central repo that everyone publishes towards is that you get a lot of lemons, and the system doesn't provide any way to newcomers to distinguish between the first-class, recommended approaches versus half-baked ideas that will get people into trouble. You'd then say, OK well someone needs to curate the collection of things - easier said than done. There's a lot of old recipes on the SQLAlchemy wiki I'd love to blow away, but , well one of my users went through all the trouble to write it and I don't want to upset him, and well OK maybe it's somewhat useful if not out of date, so it just stays up there, as a sort-of-not-quite-useful thing. Plus you need someone curating all these things in the first place. The repo starts looking like a stale graveyard for discarded ideas. For a project that is desperate to provide a consistent, simple story for newcomers (something I think Pyramid and SQLAlchemy share), these open ended repositories just add to the confusion, pushing up a large list of highly varied approaches into a flattened presentation.
God I hate Apple mail.app, the above is all on one line for me ;-)
In any case, I think the issues you bring up above already exist (e.g. search github or pypi for "pyramid" and behold the result list of stuff you never knew existed). Doing nothing will probably eventually put us in a worse position than doing something. That said, whether that something is just curating a list of third-party add-ons ala openpackages or actually maintaining a repository, I can't hold a strong opinion about, because I can't afford to drive either effort.
On Thu, Apr 12, 2012 at 10:27 AM, kiorky <kio...@cryptelium.net> wrote: > Le 12/04/2012 15:58, Michael Merickel a écrit :
> On Thu, Apr 12, 2012 at 7:41 AM, Domen Kožar<do...@dev.si> wrote:
>>> Having something like djangopackages.com + pypi classifier would >>> achieve the >>> same goal. Pull requests are also easy to make, I would propose rather to >>> have a good read about preferred way of contributing to package >>> maintainers.
>> I'm much more +1 on maintaining and improving >> http://pyramid.opencomparison.**org/ <http://pyramid.opencomparison.org/>(djangopackages). I've also >> requested on catalog-sig a "Framework :: Pyramid" trove classifier. I >> think in the era of DVCS it doesn't make much sense to attempt to >> manage organizations and commit access rights.
> For me it is now about managing rights, it is just to avoid packages > deletion. > In any case everyone get commit rights, so there are no real managment, > just a deletion barrier. > the djangopackages and the collective just complete themselves.
> Its like http://plone.org/products and the collective, they complete > themselves and are both neccesary.
This is just my own myopic point of view, but that doesn't really address a problem I find to exist in practice. Generally speaking, if I rely on an open source package, take the time to work on a bug fix or a feature, and submit a patch that includes updates to tests and documentation, then my patch is accepted with relatively little hassle. If I do a lot of work on a package and have proven myself to the maintainers, I tend to get commit rights as well. I don't mind at all not having commit rights on packages I haven't done a lot of work on directly. In that case, I want someone who has stepped up to take on maintenance responsibilities to review my patch before accepting it. Point being, ultimately, that I tend to be able to make contributions fairly easily without a model that is wide open to anyone committing anything anytime.
The tools at our disposal nowadays, with DVCS and places like Github, etc, really do make coding together in a social way much easier than it ever has been before, which I think allows more natural social structures to appear and evolve in a fairly organic way. More to the point, at least from my point of view, is these tools allow developers to maintain a model of authorship and responsibility for a package while remaining radically open to contributions from an ad-hoc community. I'd worry that the wide open collective approach would foster an environment where there might be many potential contributors, but no one taking responsibility for maintenance or peer review. I think we have the tools, now, to do better than that.
Oh, and if someone gets hit by a bus, fork their code, get consensus from the community that the new fork is the canonical version, and go. It's organic, it works.
Like some others, though, I am +1 on efforts to provide better visibility to projects that claim to interoperate with Pyramid.
> I don't want to discourage anyone from doing this, but my initial > thought, at least, is that the Plone collective came from a place > and a time where hosting your own code in public wasn't > ridiculously easy the way it is now. Now anyone can host whatever > they want on Github. Or Bitbucket, Sourceforge, Launchpad, etc.... > From reading the thread I do so that beyond just a place to host > there does seem to be a desire to have a sort of clearing house > that is one place people can go to to see what's in the collective, > which makes sense. But in this day and age, given the options to > host and distribute,
The collective was a CSV-Repository on Sourceforge in the beginning.
something anybody could get. It's true that it was easier to get svn access later than to create your own project on sourceforge, and that it's easier to put your repo into your own github account than to apply for a repo in another organisation.
The collective worked really well with it's write access for all princible. It can work better than pull requests where you have to have a maintainer who is available to merge it. Or you need to fork it and have two repositories. It's quite common with javascript projects that you have several forks on github where all contain small enhancements that are not merged into the original repository.
> that could be as simple as a web page that acts as a registry for > people's projects. Managing that might be a little bit easier and > be just as good. Just a thought.
I also like the idea of a pyramid packages directory through I'm not sure it will work out well cause most of these packages will be listed on pypi. Keeping that in sync might be tricky. But it seems djangopackages also works as pyramid packages :) http://pyramid.opencomparison.org/
..Carsten
> -- You received this message because you are subscribed to the > Google Groups "pylons-discuss" group. To post to this group, send > email to pylons-discuss@googlegroups.com. To unsubscribe from this > group, send email to pylons-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/pylons-discuss?hl=en.
On Thu, Apr 12, 2012 at 5:49 PM, Carsten Senger <sen...@rehfisch.de> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1
> Am 12.04.2012 14:23, schrieb Chris Rossi: > > I don't want to discourage anyone from doing this, but my initial > > thought, at least, is that the Plone collective came from a place > > and a time where hosting your own code in public wasn't > > ridiculously easy the way it is now. Now anyone can host whatever > > they want on Github. Or Bitbucket, Sourceforge, Launchpad, etc.... > > From reading the thread I do so that beyond just a place to host > > there does seem to be a desire to have a sort of clearing house > > that is one place people can go to to see what's in the collective, > > which makes sense. But in this day and age, given the options to > > host and distribute,
> The collective was a CSV-Repository on Sourceforge in the beginning.
> something anybody could get. It's true that it was easier to get svn > access later than to create your own project on sourceforge, and that > it's easier to put your repo into your own github account than to > apply for a repo in another organisation.
> The collective worked really well with it's write access for all > princible. It can work better than pull requests where you have to > have a maintainer who is available to merge it. Or you need to fork it > and have two repositories. It's quite common with javascript projects > that you have several forks on github where all contain small > enhancements that are not merged into the original repository.
> > that could be as simple as a web page that acts as a registry for > > people's projects. Managing that might be a little bit easier and > > be just as good. Just a thought.
> I also like the idea of a pyramid packages directory through I'm not > sure it will work out well cause most of these packages will be listed > on pypi. Keeping that in sync might be tricky. But it seems > djangopackages also works as pyramid packages :) > http://pyramid.opencomparison.org/
> ..Carsten
> > -- You received this message because you are subscribed to the > > Google Groups "pylons-discuss" group. To post to this group, send > > email to pylons-discuss@googlegroups.com. To unsubscribe from this > > group, send email to pylons-discuss+unsubscribe@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/pylons-discuss?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To post to this group, send email to pylons-discuss@googlegroups.com. > To unsubscribe from this group, send email to > pylons-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/pylons-discuss?hl=en.
> On Thu, Apr 12, 2012 at 7:41 AM, Domen Kožar<do...@dev.si> wrote: >> Having something like djangopackages.com + pypi classifier would achieve the >> same goal. Pull requests are also easy to make, I would propose rather to >> have a good read about preferred way of contributing to package maintainers. > I'm much more +1 on maintaining and improving > http://pyramid.opencomparison.org/ (djangopackages). I've also > requested on catalog-sig a "Framework :: Pyramid" trove classifier. I > think in the era of DVCS it doesn't make much sense to attempt to > manage organizations and commit access rights. You and your > maintainers own the project repo, other people can submit pull > requests. What is more important is that the source repositories are > easy to find, for which I think the opencomparison page does a good > job. I think the opencomparison page needs much more visibility within > the community.
+1 to Domen and Michael. It's important to have and easy way to find Pyramid addons and a service like opencomparison.org could be a good choice.
i think the big issue is about marketing and critical mass, and less
about the exact details of functionality.
I think a lot of concerns could be solved in two steps:
1. getting a "Framework :: Pyramid" classifier, which has been
requested
2. having a page/module on the Pyramid site that does this:
table 1: official pyramid plugins
table 2: community plugins
grid based view that shows in alphabetical order
[ name ][ pypi page][ homepage(bitbucket/github/site) ][ description ]
everything in the grid would be auto-updated based on the
"Framework :: Pyramid" classifier. it's one huge list.
the opencomparison engine is a nice bell/whistle -- but one of the big
things that got the django community moving was that there were many
huge lists of packages early on. there are a 2700 packages
referencing django on pypi and 220 for pylons.
the best way to show that pyramid is a vibrant community is to make
all the activity going on around it look as substantial as it really
is.
I am a solid +1 on creating a clear list of packages that are in some way oficially approved and recommended for use. I am ready to volunteer to do some simple work on that (also ready for serious tasks but am a bit shy).
