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

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.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

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


_______________________________________________
Pharo-project mailing list
[hidden email]
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?

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.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

I like the idea of a maintenance group.

stef

On May 20, 2010, at 11:46 PM, Sean P. DeNigris wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project