[Pharo-project] Community Development (a suggestion)
Since there is a major push in both Squeak and Pharo to be clear about what's loading where, and get more and more projects loadable; and the community is fixing projects that we don't own... I propose: 1. Everyone make your SqS repos globally writable unless you have a reason not to. 2. SqS admins, send an email to all the repo admins requesting this. Motivation: I've been fixing many projects as I try to load them, as a service to the community, but I am not necessarily taking on being responsible for their long-term maintenance. Right now, the process seems to be: 1. Upload fixes to my own repo 2. Email the project admin (if they are even still findable) 3. Post to the mailing lists with the new link 4. Wait for a response Not only is this more complicated than it has to be, but creates confusion. For example, I fixed ExternalWebBrowser to work in Pharo, but couldn't upload it to the project repo. Now I fixed the ConfigurationOf. Where do I put it? If I put it in the usual places, it will now point to my personal repository. It doesn't seem right to hijack someone else's project this way. And it's confusing for users - why are there two ExternalWebBrowsers and ConfigurationOfs on squeaksource? Thanks. Sean -- View this message in context: http://forum.world.st/Community-Development-a-suggestion-tp2224670p2224670.h... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Sean P. DeNigris wrote:
Since there is a major push in both Squeak and Pharo to be clear about what's loading where, and get more and more projects loadable; and the community is fixing projects that we don't own...
I propose: 1. Everyone make your SqS repos globally writable unless you have a reason not to. 2. SqS admins, send an email to all the repo admins requesting this.
I don't think using global write is the right way to fix the problem. 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 This solution wouldn't get you a fast response, but would guarantee you an eventual response. And, the project admins will still be in charge, which is as it should be, IMO.
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? There are currently many projects that have this setup, and of course it would be up to each admin. Has anybody out there experienced problems with r/w repos that caused them to change to read-only? That would make a case for caution. 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. 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 Sean -- View this message in context: http://forum.world.st/Community-Development-a-suggestion-tp2224670p2224980.h... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Has anybody out there experienced problems with r/w repos that caused them to change to read-only? That would make a case for caution.
I got student publishing other versions and this was not optimal. I think that it would be good to garbage collect squeaksource somehow. Stef
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.
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
Sean -- View this message in context: http://forum.world.st/Community-Development-a-suggestion-tp2224670p2224980.h... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.
Yanni Chiu wrote:
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.
Ah, now I see what you're saying. I actually agree. My idea is to encourage and default to w/r, not impose it. I assume that many projects are read-only, not because of a desire of the maintainer, but just because that's the default in SqS. Why not default to r/w, making life easier for the community, and admins can select read-only if they want. Yanni Chiu wrote:
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.
Sounds interesting. Sean -- View this message in context: http://forum.world.st/Community-Development-a-suggestion-tp2224670p2225365.h... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
I like the idea of a maintenance group. stef On May 20, 2010, at 11:46 PM, Sean P. DeNigris wrote:
Yanni Chiu wrote:
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.
Ah, now I see what you're saying. I actually agree. My idea is to encourage and default to w/r, not impose it. I assume that many projects are read-only, not because of a desire of the maintainer, but just because that's the default in SqS. Why not default to r/w, making life easier for the community, and admins can select read-only if they want.
Yanni Chiu wrote:
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.
Sounds interesting.
Sean -- View this message in context: http://forum.world.st/Community-Development-a-suggestion-tp2224670p2225365.h... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
Sean P. DeNigris -
Stéphane Ducasse -
Yanni Chiu