Sean P. DeNigris wrote:
Yanni Chiu wrote:
I don't think using global write is the right way to fix the problem.
Why not? What is the concrete negative scenario that it creates?
It takes away the admin's responsibility to administer. The admin can enable global write, if they chose. If global write is imposed, then the admin may feel less responsible for what is happening to the project. Why have an admin role at all, if everything is world writable?
Yanni Chiu wrote:
How about a SqS usage policy: - the project admin(s) are responsible for keeping their email contact up-to date - periodically (monthly?), project admins are ping'ed. If no acknowledgement is received after three attempts, then the project admin reverts to the community - any community member can then ask to become the project admin
I like this as an addition, but it doesn't solve the primary issue of making it easy for people to contribute. I know that currently, every time I go through the process of contacting someone to apply changes, I think, "this is too hard." I'm sure that many fixes out there are lost because of the private development model.
It's really up to each project to make it easy/hard to accept contributions. I don't see what outsiders could do to change that, other than to ask to become an insider. An idea comes to mind though. Maybe a "maintenance" group could be created. Members of the maintenance group would have write permissions to all projects. They would only submit code to make things work on different platforms, but would not wildly re-factor, change the design, add features, etc. That way, the admin/dev's would still maintain "control" of their project, but get help from the maintenance crew.
How about this: * As you suggest above: projects revert to community after x time * there is an inbox-like place for every project (or one for all external projects), where community contributions can go. This way, the latest code is always available, and it is separate from the owners code
That seems like a reasonable idea.