Garrett: Linux Foundation quietly drops community representation
Garrett: Linux Foundation quietly drops community representation
Posted Jan 21, 2016 3:51 UTC (Thu) by josh (subscriber, #17465)In reply to: Garrett: Linux Foundation quietly drops community representation by piotrjurkiewicz
Parent article: Garrett: Linux Foundation quietly drops community representation
Posted Jan 21, 2016 5:00 UTC (Thu)
by piotrjurkiewicz (guest, #96438)
[Link] (12 responses)
I think that every sane person (and I believe open source community consists mostly of such people) would admit that this was a serious misconduct and deviation from the Gnome original mission, as well as from open source ideals, like only-merit-based collaboration and selection (of both code and people).
[1]: Just compare OPW projects quality and results to GSoC projects results. In GSoC participants are being selected basing on merit instead of sex.
Posted Jan 21, 2016 5:34 UTC (Thu)
by josh (subscriber, #17465)
[Link] (11 responses)
OPW was funded through donations supplied specifically for that purpose, not from general donations to GNOME.
It's remarkable how much misinformation exists around that point. Consider whether there's a reason for that, and what agenda people might have that would motivate them to stir up and propagate such misinformation.
> Just compare OPW projects quality and results to GSoC projects results.
Happily. Having participated as a mentor multiple times in both GSoC and OPW, I found the OPW participants to have *drastically* higher quality. There are also statistics readily available for both the volume of contributions and the subsequent employment of participants. Also, the OPW program has a much more rigorous selection criteria compared to GSoC; for instance, the OPW project for the Linux kernel requires demonstrating the ability to successfully produce and submit patches.
Posted Jan 21, 2016 13:58 UTC (Thu)
by chirlu (guest, #89906)
[Link] (1 responses)
Don’t the GSoC mentoring organizations get to choose who they accept as a GSoC student? That was my understanding of the process, though I may be mistaken. If it is the case, I’d think it’s the fault of the organization if they end up with a GSoC student who can’t successfully produce and submit patches.
Posted Jan 23, 2016 15:01 UTC (Sat)
by krake (guest, #55996)
[Link]
Yes, they do.
However, some of the participating organizations gets hundrets of applications and it becomes difficult to find distinct yet suitable smaller tasks that applicants need to solve before considered eligible.
There is also quite some system gaming involved, e.g. applicants getting their intro tasks solved by more senior students at the same university for some share of the money.
But all organizations try their best to select the most approriate candidates and I am pretty sure the very same organizations treat selection in the Outreachy program with the same considerations.
Posted Jan 21, 2016 17:21 UTC (Thu)
by piotrjurkiewicz (guest, #96438)
[Link] (8 responses)
I was talking about projects quality, not participants quality. About half of OPW projects were things like documentation writing, graphic design or testing. Whereas most GSoC projects are true programming tasks.
> OPW program has a much more rigorous selection criteria compared to GSoC
And the most rigorous one is gender and sexual orientation...
> for instance, the OPW project for the Linux kernel requires demonstrating the ability to successfully produce and submit patches.
These are internal Linux Foundation regulations, not OPW ones. Every mentoring organization can set up any criteria it wants. In fact I participated in GSoC twice, and in both cases my mentoring organizations required to submit patches before selection.
Moreover I would like to point out that in GSoC mentoring organization doesn't know participant sex during the selection process. This information is only available to Google, but Google has no influence on selection. Of course mentoring organization can infer participant sex from his/her first name, but many students use nicknames instead their real names during the program. So in this case selection is completely blind regarding to gender factors.
Posted Jan 21, 2016 18:08 UTC (Thu)
by josh (subscriber, #17465)
[Link] (3 responses)
Which is much harder to get people to actually do in Open Source projects. Valuing code and devaluing everything else causes major problems in many Open Source projects.
As for your repeated complaints about the audacity of creating a program to support under-represented groups, I will reiterate that that program is supported specifically by people donating to it, and thus presumably agreeing with its goals, which already entirely counters your original complaint.
Apart from that, multiple studies have shown that attempting to pay attention only to "merit" typically produces results contrary to that goal; instead, people asked to pay attention only to "merit" typically disproportionately favor those who look and think like themselves. A program designed to counterbalance that tendency seems entirely sensible.
Now, to bring this back on-topic: how is *any* of this relevant to the idea that the Linux Foundation changed its bylaws to drop board members elected by individuals? The entire issue only came up in this context because of this change to the bylaws with remarkably coincidental timing. No particular candidate up for election *should* be relevant to that change; changing the rules with any specific candidate in mind seems deeply scummy. Best-case, that change is unrelated, and still unfortunate.
Posted Jan 21, 2016 18:46 UTC (Thu)
by piotrjurkiewicz (guest, #96438)
[Link]
In GSoC selection phase mentoring organizations don't know how candidates look like and what their gender is (if student is using a nickname). So there is no need to 'counterbalance' it with a similar program limited to minorities.
But let's leave this topic, as Jonathan suggested.
> changing the rules with any specific candidate in mind seems deeply scummy
I agree, but such things happen. And changing the rules with the SFC-VMware lawsuit in mind (as mjg59 speculated) seems even more scummy.
Posted Jan 21, 2016 21:39 UTC (Thu)
by jspaleta (subscriber, #50639)
[Link]
As greg wrote in reddit in defense of the change, It might be common for non-profits with self-perpetuating boards to not notify their non-voting membership when a bylaw amendment comes up. But I don't think its considered a best practice.
But the reality non-profits generally have a lot of leeway in how they construct the procedure they use in bylaw amendment. So there's nothing technically wrong with the fact that this board has the power to amend the bylaws without input from the membership..as stated in these bylaws. It just maybe... unfriendly to do so without notice in this case, and makes a space for the board's intent to be misinterpreted, since this impacts membership benefits and it doesn't appear to be a change imposed by government regulation changes.
Make no mistake, there are good reasons to give a board the power to amend bylaws at need without delay and without requiring input from membership. But if there's no expressed need for quick action to address an immediate business or legal requirement, then perhaps the board should choose to provide notice to membership as a standing discretionary policy, in order to get non-binding feedback to make the best informed decision possible. At the very least, is someone pops up and hates the proposed changed, they won't want be able to claim the board stabbed them in the back when they weren't looking. The board will be able to make the case that they stabbed that particular person in the face...for very good reasons. And really.. sometimes..that's the best we can hope for when changes happen... to see it coming no matter how powerless we are to stop it and no matter how painful it is when it finally comes.
If we could roll the clock back on this, and the board had issued a notice concerning the proposed amendment to membership for feedback with a statement as to the reasoning for the proposed amendment... would the timing of the final vote to adopt have been as suspicious? Maybe not. I doubt that it would have.
-jef"... still trying to blame Canonical for this..."spaleta
Posted Jan 22, 2016 0:18 UTC (Fri)
by ksandstr (guest, #60862)
[Link]
Hogwash. A consciously-designed counter[-1] to an arguably[0] flawed setup will be at least equally flawed, and almost certainly more so due to (e.g.) the cognitive biases, preconceptions, imperfect modeling, etc. at play while setting it up. In terms of an example, meritocracy may[0] end up favouring whitey, but a "counterbalance" program defined to exclude whitey is outright racist despite seeming like an "entirely sensible" idea (to some).
Consider this: is a counter-$foo always better if $foo has a flaw, an imperfection? And if so, why isn't everything perfect already -- surely everyone's ancestors would've iterated the counter-whatever until all rain became Brawndo?
That's not to pretend ignorance of where these outreach programs come from: they're designed by feminists to further feminist causes. Because it is formally neutral, meritocracy disfavours the women-only ideal; so feminist ideology demands it be torn down and, in practice, replaced with what looks, sounds, and smells exactly like a ruling clique's say-so. This is supposedly better, though curiously there's never any studies showing this; only doctrine that's been shown silly (as above) at a mechanical level -- nor is there a reason why anyone would prefer to be lorded over by a kakistocratic knitting society[1].
[-1] and it's certainly not a balance: that would be dynamic. In practice women's outreach programs rarely have a termination or proportionality clause to (say) compensate for their own success, i.e. so as to not produce a Girls-Only Tree House.
Posted Jan 21, 2016 22:10 UTC (Thu)
by pboddie (guest, #50784)
[Link] (2 responses)
True programming tasks! Once upon a time, things like documentation and tests were regarded as essential deliverables in any complete system. And contrary to what the delusional "the code is the documentation" bandwagon might claim, their absence inhibits the adoption and further development of software. Writing good documentation is pretty difficult. No, running Doxygen on the code does not produce good, complete documentation. And if only the people writing the code actually bothered to try and write proper documentation, they'd probably produce better code as well. But I suppose "true programmers" are too busy writing their "high-quality" code to appreciate any of this. No wonder some projects are in a mess, others can't attract and retain productive contributors, and people are cooking up new projects that are supposedly better than existing ones all the time, only for those to flame out, too, and for everyone to move on to the next new shiny thing. True programmers!
Posted Jan 22, 2016 5:39 UTC (Fri)
by voltagex (guest, #86296)
[Link]
Posted Jan 23, 2016 15:11 UTC (Sat)
by krake (guest, #55996)
[Link]
Agreed.
I.e. developer documentation vs. end user documentation
Posted Jan 23, 2016 15:05 UTC (Sat)
by krake (guest, #55996)
[Link]
Not due to selection of proposals but because that is the condition by the program's sponsor, Google.
> And the most rigorous one is gender and sexual orientation...
Actually GSoC has a much more rigorous base selection criteria by requiring applicants to be enrolled at an accredited university or college.
Which applies to a far smaller percentage of the overall population, no?
Posted Jan 21, 2016 19:37 UTC (Thu)
by eean (subscriber, #50420)
[Link]
Garrett: Linux Foundation quietly drops community representation
Garrett: Linux Foundation quietly drops community representation
Garrett: Linux Foundation quietly drops community representation
Garrett: Linux Foundation quietly drops community representation
Garrett: Linux Foundation quietly drops community representation
Garrett: Linux Foundation quietly drops community representation
Garrett: Linux Foundation quietly drops community representation
Garrett: Linux Foundation quietly drops community representation
http://www.dummies.com/how-to/content/roberts-rules-for-a...
Garrett: Linux Foundation quietly drops community representation
[0] I call your multiple anecdotes of studies, and raise you the wind whispering in my ear
[1] besides the foolish idea of being one of The Chosen after Year Zero, rather than a trod-upon factory slave
Garrett: Linux Foundation quietly drops community representation
I was talking about projects quality, not participants quality. About half of OPW projects were things like documentation writing, graphic design or testing. Whereas most GSoC projects are true programming tasks.
Garrett: Linux Foundation quietly drops community representation
Garrett: Linux Foundation quietly drops community representation
But even if it would that would only solve one aspect of documentation, i.e. how the software does things.
It would still leave the need to document how to use the software.
Garrett: Linux Foundation quietly drops community representation
Garrett: Linux Foundation quietly drops community representation