Re: Sugar-devel Digest, Vol 22, Issue 97 (Patch review/Community et al.)
Yioryos Asprobounitis <mavrothal <at> yahoo.com>
2010-09-01 09:48:55 GMT
--- On Tue, 8/31/10, sugar-devel-request <at> lists.sugarlabs.org
<sugar-devel-request <at> lists.sugarlabs.org> wrote:
> 3. Community (was: Re: Bug tracking
> Vs Patch review) (Sascha Silbe)
> 5. Re: Community (was: Re: Bug tracking
> Vs Patch review)
> (Tomeu Vizoso)
I'm not a sugarlabs member but I read the list and a felt I should "pollute" it with my 2 cents on this issue.
This is a very interesting discussion, but I think it may be missing the point (and is turning ugly).
FOSS is big enough and everyone can find a big number of successful, and probably a bigger number of failed,
projects that follow one or the other patch submission process or more general, organizational
What this tell us is that there is not only one "best practice" and more important that the best practice for a
given project is "the one that works".
The project is what it is, the people are who they are, the major players are given to a large extend and the
others are coming and going according to what they see from outside and experience from inside.
"Personal exchanges" may be unavoidable but not necessarily helpful if they are not starting from a common ground.
So the first point to agree on is if/how "things work". The answer to this question is the basis for any
further discussion. If they are we "ok" then we may discuss fine tuning the current processes much more
efficiently. If they are not, then the real issue is how to overhaul the system and specific problems are
blown out of proportion.
"Works" is a very vague term of course, and in this mail exchange we see individual opinions for both.
However, singled out cases may simply be just that and not reflect the bulk of the cases eg reality.
Specific questions, and more important some "metrics" may clarify a bit "how are we doing". For example:
- Does the code quality improves with every consecutive release (check for features, code efficiency, bug
squashed, tickets/release, etc)?
- Are we free of regressions?
- Is our user base increased because of our new releases (query activity downloads for Sugar version)?
- Are we (almost) free of long standing issues and no one appears to be willing to tackle them (check
bugtracker for stale tickets)?
- Did the number of people involved and contributing, increased (check git for new and inactive projects
with a monthly window)?
- Can this be attributed to our current process and organizational scheme, to any extend (text main mailing list?)?
- Did developers left the organization with the usual or lower rate for FOSS projects (query devel
subscribers, list/git contributors on a monthly basis. Ask/get dada from other similar size projects)?
- Is our membership growing (this should wait till the registration deadline)?
- Do we have a strong positive feedback from other distro developers and packagers (release manager? could
- Do we have a strong positive feedback from our users (XYZ? should provide info - BTW why there is not any
- And for the "igniting" issue: Is the average time for patch acceptance/rejection lower or equal to other
similar (in size) projects (check track/list/git and compare)?
A majority of "yes" in these questions means that things "work" and we should just try to improve if needed
A majority of "no" means things should change. Try alternatives and keep monitoring trends. Reevaluate as needed.
I do not know any of the answers to these (or other relevant) questions but I hope is "yes". The subscribers of
this list should know though. They should also know the answer to probably the most important question "am
I happy with this project"?
Maybe a relevant questionnaire could be included in the upcoming SLOB election, so the new SLOB can
consider it in due time.
I think that is important to know what the contributing volunteers think and feel about the organization
and not consider their participation or not as their only (and ultimate) "vote". "My way or the highway"
works when you put the money, you already are a very successful project or you have strong approval. Is
important to know if the 3rd at least is true.
A ballot approach will (hopefully) also avoid heated exchanges and should not "put on the spot" anyone.