On Thu, Apr 12, 2012 at 10:27 AM, kiorky <[email protected]> wrote:
> Le 12/04/2012 15:58, Michael Merickel a écrit : > > On Thu, Apr 12, 2012 at 7:41 AM, Domen Kožar<[email protected]> 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. Chris -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
