Re: foundation application..



> This is something I believe could happen if an amendment were to be
> proposed with compelling evidence to support it so we are able to take an
> informed vote on it. At the moment the issue is that a decision which
> overrides the bylaws has already been made in the establishment of this
> policy, which means members are put in a position where we have to defend
> the bylaws but that the policy decision somehow doesn't seem to have to be
> defended with compelling evidence - which is the wrong way round.

I believe the bylaws are followed. As such, I don't think any amendment
is needed. Further, it seems though there should be improvement, it is
quite clear. Andrea showed the bit where bylaws state that actual
discretion is for membership committee.

This only holds true if the membership committee are viewing applications on a case by case basis, it does not mean they can decide to apply a new blanket exception to a group of illegible contributors which excludes those people from applying in the first place.

For various things the foundation delegates responsibility to the
various teams. These teams have then additional rules in place. That
these are in the bylaws or not is not IMO unimportant. I think the rules
per team (delegated area) should be clear.

Absolutely, but committee policies still should take steps to avoid overriding the bylaws otherwise the rules they make are unclear as well as being invalid.

> IMO if there's a valid concern then it really
> > doesn't matter to spend so much time on if they're allowed or not.
>
> Therein lies the core difference in how we perceive this: I believe the
> concern may be valid enough to investigate, but I do not believe the
> "problem" has been quantified and therefore I do not believe the argument
> for this policy is substantiated and hence I do not believe it is a waste
> of time to spend so much time on if they're allowed to act on the
> assumptions that have been made about it. Moreover, we have no idea whether
> this approach is actually causing more harm than good. It could actually be
> making more interns unwelcome and unappreciated and deterring them from
> continuing to contribute to the project. We are generally acting on an
> awful lot of assumptions by taking action to address a perceived problem
> which we really haven't analysed concrete data for.

The problem was highlighted many years ago on various occasions: Mentors
spend a lot of time, to only have the person vanish after the period.
This partly due to wrong perception. You're not going to have 100% of
the people stay. IMO 1 in 5 is more realistic. I guess we should track
these people.

I forgot when GNOME started participating in GSoC. Wikipedia shows this
started in 2005. The discussions around this are nothing new.

In another message regarding this I noticed people are mostly talking
about the outreach program. I know little about that. I'm mostly talking
about GSoC.

Yes, as mentioned this has raised some questions for me, too. Thanks for clarifying your own position.

I have noticed way more people whose names I don't recognize at all, but
doing cool things. Unfortunately no clue where they're from.

This is another problem which arises from not assessing this quantitatively. We just don't get the full picture when we solely rely on anecdotes and our own myriad personal experiences which are different to one another's.
 
> > Those following, might have noticed that this was done in the opening part
> > > of the discussion and it seemed to be generally agreed that some interns
> > do
> > > make non-trivial contributions. At least, nobody seems to have disagreed
> > > with that idea, anyway.
> >
> > Most interns seem to vanish quite quickly after their internship is
> > over. Maybe not true at all anymore, there are a few exceptions, but
> > that has been a topic of discussion for various years.
>
> The question is not just about whether they most of them vanish, although I
> agree that's clearly part of it. We need to be able to compare their
> behaviour to other kinds of contributors statistically, accounting for all
> our sources of error, before we can begin to make any assumptions
> or predictions about this model. Let's see the raw data and analyse it
> first.

For the various programs out there (I mostly followed GSoC) people not
staying with GNOME is IMO something was clearly a problem. If it still
is, no clue.

As you indicate, this perceived problem has been discussed a lot over the years. It seems like that's another compelling reason to explore it scientifically and determine the merits of any proposed solutions using a strategic, evidenced-based and impartial approach.

Doing investigations, cool. But IMO there was enough concern regarding
this.

As far as I can tell, the concern comes from the membership committee wanting to reduce applications from interns who may not end up using their membership and in any case, none of the concerns raised have actually been quantitatively evidenced.

Anyway, this is too much theoretical talk so I'm going to switch to a
proposal instead. Getting more concrete:
  I think in the "guidelines" for applying, there should be a mention
  that membership committee has seen that interns (GSoC, etc) often
  leave so it is highly preferred that the intern waits two months
  before applying. At the same time, it should clearly state that 1) the
  participation was already enough 2) it is not encouraged, but they can
  apply anyway.

It seems proportionate to try to seek compelling evidence to support the hypothesis that this is a problem but also that the suggested solution will address that problem in a representative way.

Regarding 1: Is participation actually enough? Based on the responses here it seems like for some it might be enough and for others, applying a blanket rule one way or another could lead to problems, if this initial assumption is wrong.

Regarding 2: if the assumption that participation is always enough is correct, then we would then need to ask why making an application would not be encouraged and decide whether this is fair and representative.

On the basis that we don't have the answers to those questions and that there a wider implications (some of which, Meg has also highlighted) in this, I would personally have to be against another proposal this similar to the one of the membership committee, at this point in time. For the time being, I think my suggestion that we do not any contributor to approach membership applications differently to any other kind of contributor until we have at least analysed the raw data and produced a concrete report about what it may indicate is a good place to start, if we really want to ensure the membership is truly representative of GNOME's community of contributors.

Look at it this way: If this has been such a long running concern why the rush to address it before we have looked into what "it", actually means in context? Let's look at the associated risks of the suggested approaches, here: If we investigate this before proposing anything then the worst thing that can happen, is that the membership committee have had to deal with a bit of extra paper work for a finite period of time until we have the evidence to show that this is the case which we can share with future generations of GNOME contributors to come.The worst thing that can happen if supporters of this membership committee policy are wrong and we go with the idea to not investigate that, is we have broken our own bylaws to introduce a practice which discriminates against a group of contributors unfairly, possibly deterred some contributors away from the project by undervaluing them, biased our own democratic processes by artificially creating an imbalance our membership so that it is unrepresentative of the community of contributors as a whole and that we still won't have any evidence to tell us whether or not it was all worth all that because we never sought to determine the what consequences of our actions would be in the first place (i.e. the same concerns about the inferred risks of this practice, would not go away).

Magdalen



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]