What about a pyramid collective ?

[kiorky]

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.

    - http://plone.org/documentation/glossary/collective
    - https://github.com/collective/ (new)
    - http://svn.plone.org/svn/collective/ (old)

Fortunately, This is reproducible for us.

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.

Also there is some docs on the collective administration there : http://collective.github.com/

-- 
Cordialement,
KiOrKY
GPG Key FingerPrint: 0x1A1194B7681112AF
Pensez à l’environnement. 
N’imprimez ce courriel que si vous en avez vraiment besoin.

[Chris McDonough]

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?

- C

[Gael Pasgrimaud]

+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-...@googlegroups.com.
> To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
>

[kiorky]

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...

[kusut]

I am volunteering

No more manual repo searching or IRC logs digging

> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To post to this group, send email to pylons-...@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-discus...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-discuss?hl=en.
>

--
kusut.web.id

[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, 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

[Domen Kožar]

My two cents: 

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

[Michael Merickel]

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.

[kiorky]

Le 12/04/2012 14:41, Domen Kožar a écrit :

My two cents: 

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 + 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-...@googlegroups.com.
To unsubscribe from this group, send email to pylons-discus...@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-...@googlegroups.com.
To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.

-- 
Cordialement,
kiorky

[kiorky]

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/ (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.
>

--
Cordialement,
kiorky

[Michael Bayer]

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.

[Chris McDonough]

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.

- C

[Chris Rossi]

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/ (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.

Chris

[Carsten Senger]

-----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.

http://collective.cvs.sourceforge.net/viewvc/collective/

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-...@googlegroups.com. To unsubscribe from this
> group, send email to pylons-discus...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-discuss?hl=en.

- --
Carsten Senger - Schumannstr. 38 - 65193 Wiesbaden
sen...@rehfisch.de - (0611) 5324176
PGP: gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xE374C75A
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJPhvmdAAoJEAOSv+HjdMda+PwH/RXixVBt/JMyUE3Chjh0uaxB
Ni0H1tDgY/Wo+A+U4BmF09fT11hl0O7Y5R+MG/DBXkMeHTVORRB3o/XUO87gW8DY
WdheQkhvGZRGILxB+jb3+hfKSEct1Dqb0/qpGRBqktzF/9I9WvpEcpTqNP39umCt
bPcexLj7uGE2ky+lA78/+HCFNHv5cEhebJr6w7aRk7EQ/VSmmG6kIbOIQ8AjUaNu
gHM1dKaYILaeGg3zak60ZXEtM00RAFp+FPV7nZCNsDBcvrGTUb2U+Bce3X/ZNYYx
dCogCT1n+Pz9HpqxYE80O+n479H5DIG5zIIiatvn88G2LVnaRtqllkRfb9xjbGw=
=wgWh
-----END PGP SIGNATURE-----

[Domen Kožar]

If we have all the scaffold by default include pyramid pypi classifier, that should take care of most packages by default

[Stefano Fontanelli]

Il 12/04/12 15.58, Michael Merickel ha scritto:

+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.

--
Stefano Fontanelli
Asidev S.r.l.
Viale Rinaldo Piaggio, 32 - 56025 Pontedera (Pisa)
Tel. (+39) 333 36 53 294
Fax. (+39) 0587 97 01 20
E-mail: s.font...@asidev.com
Skype: stefanofontanelli

[Jonathan Vanasco]

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.

[Andrew Mleczko]

I'm also very +1 on this.

[Максим Коринец]

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).