Sugar Labs - User contributions [en]

User:Tbadsha

2008-12-22T07:55:59Z

Tbadsha:

=Hello=
I am an Electrical Engineer with an undergraduate degree from University of Peshawar and a Masters from University of Houston. Worked for Sperry Univac and Bell Labs, developing Operating Systems software for 13 years before moving to NCR corporation where I developed solutions for large accounts for about 3 years. Following that I worked in the Computing Services Division of Abu Dhabi National Oil Company and was the Head of the User Support Services prior to joining the Government of Pakistan as Member (IT). Remained at this position for 7 years, where I was responsible for the IT program of the Federal Government. In this tenure I worked on IT programs for various sectors including education. I have been working as an IT Consultant since April 2008 and a volunteer contributor to the OLPC team in Pakistan and Sugar Labs.

== Contribution ==

Developed a proposal for extending Sugar Development to other regions in order to gain local appropriation of knowledge and provide an infrastructure for support and deployment.

== Current Status ==

Helping NUST, a leading university (http://www.nust.edu.pk/) in Pakistan, to draft a project proposal for developing e-learning applications and creating a standard methodology for porting Sugar to other Platforms - particularly used computers. Created an informal relationship of Zigron, Inc. (http://www.zigron.com/) a software consulting and outsourcing company specializing in Web 2.0 Application Development with the University. Zigron, Inc with competency in e-learning applications and embedded software will be partners in this initiative.

== Contact ==

tbadsha at yahoo.com

User:Tbadsha

2008-12-22T07:45:06Z

Tbadsha: Profile and Contribution of Tariq Badsha to Sugar Labs

=Hello=
I am an Electrical Engineer with an undergraduate degree from University of Peshawar and a Masters from University of Houston. Worked for Sperry Univac and Bell Labs, developing Operating Systems software for 13 years before moving to NCR corporation where I developed solutions for large accounts for about 3 years. Following that I worked in the Computing Services Division of Abu Dhabi National Oil Company and was the Head of the User Support Services prior to joining the Government of Pakistan as Member (IT). Remained at this position for 7 years, where I was responsible for the IT program of the Federal Government. In this tenure I worked on IT programs for various sectors including education. I have been working as an IT Consultant since April 2008 and a volunteer contributor to the OLPC team in Pakistan and Sugar Labs.

== Contribution ==

Developed a proposal for extending Sugar Development to other regions in order to gain local appropriation of knowledge and provide an infrastructure for support and deployment.

== Current Status ==

Helping a leading university (http://www.nust.edu.pk/) in Pakistan to draft a project proposal for developing e-learning applications for the Sugar Platform and creating a standard methodology for porting Sugar to other Platforms - particularly used computers.

== Contact ==

tbadsha at yahoo.com

Sugar Labs/Funding

2008-09-08T17:29:14Z

Tbadsha: /* Funding FOSS Projects to Increase Participation */

<noinclude>{{ GoogleTrans-en | es =show | bg =show | zh-CN =show | zh-TW =show | hr =show | cs =show | da =show | nl =show | fi =show | fr =show | de =show | el =show | hi =show | it =show | ja =show | ko =show | no =show | pl =show | pt =show | ro =show | ru =show | sv =show }}</noinclude>
==Mako's Essay on Funding Free Software Projects (extract)==
''Regardless of the steps that a project chooses, transparency will act in a central role in maintaining volunteerism.'' — Mako Hill

I thought we could use this text, taken from Mako's essay, [http://mako.cc/writing/funding_volunteers/funding_volunteers.html "Problems and Strategies in Financing Voluntary Free Software Projects"], as a starting point for a discussion on what sorts of activities Sugar Labs should be funding. In the essay, Mako takes a strong stance against the introduce of paid labor into a primarily voluntary free software project, so this is far from a neutral starting point. Nonetheless, let the discussion begin! --[[User:Walter|Walter]] 13:26, 28 May 2008 (UTC)

----

"The safest way for voluntary free software organizations to spend money without compromising voluntary labor is to not pay for labor -- and the production of code in particular -- or to fund labor indirectly.

"One great way to do this, employed frequently by the Debian project, is to use donations to '''purchase hardware to help facilitate development'''. The most frequent and largest types of expenditure by the Debian project and its supporters is hardware for servers, other forms of infrastructure, and bandwidth. Each of these are viewed as shared resources within the project which avoids the appearance of paying an individual and valuing some contributions more than others — even if an individual makes disproportionately large use of the machine or infrastructure in question. When a developer steps down, the project infrastructure they use is passed on to another volunteer.

"Another good way to fund projects is to '''build "capacity."''' Capacity describes work or resources of any organization devoted to something other than the groups' core goal but that makes the project more effective or efficient. Developing or building an accounting system is a good example of capacity. Because it is outside of the core goals and work of the project, funding capacity is less likely to crowd voluntary workers out. Since infrastructure and increased or improved capacity can help an entire project run more smoothly, funding capacity in this way can help a voluntary organization become more streamlined and effective with only very minimal risks of crowding out volunteers, affecting transparency, or resulting in a lower quality product.

"Another good low-risk solution is to use funds to organize or '''sponsor conferences, seminars, meetings or workshops'''. For groups with less funding, money can be spent on securing a venue, bandwidth, food for attendees, or other conference expenses. For projects with more funding, need-based or merit-based travel aid can be offered to help attendees reach the conference. Conferences provide a venue for sharing information between members of a volunteer team, allow for in-person brainstorming and design sessions, help increase the quality of relationships between members of the project, and can act as a reward to "sponsored" developers.

"DebConf, the annual Debian conference, is a good example of '''strategic conference funding''' and is how the Debian project spends the vast majority of funding each year. Lodging, bandwidth, the conference venue, and food are normally paid for all attendees based on a first-come-first-served basis until funds are depleted. Additionally, travel aid is offered on a combination of need and merit based systems going first to speakers with accepted proposals, then to official Debian developers, and finally to qualified contributors to the project over the previous year. Funded conference attendance acts both as a reward for active volunteers and a step toward creating a positive, fun, and highly educational event for all attendees. Each year, there are participants who are less involved in the Debian project before the conference but who increase their involvement after. Additionally, DebConf acts as a venue for airing ideas and proposals between developers and for gathering feedback on controversial issues.

"A related, and sometimes overlapping model of funding involves funding '''code sprints'''. Popular in the Python and Zope communities and with increasingly popularity elsewhere, sprints are intense sessions of development — usually around one week long. They are used as catalysts for development and have seen major leaps forward in the development of features and code within very small amount of time. Sprints are like conferences in most aspects except that the emphasis is more on the production of code and sustained hack-sessions than on presentations and discussions. They also usually involve less people than a conference and attendees are usually limited to the most actively involved volunteers on a project. The Plone Foundation and SLX Debian Labs in Norway has effectively used the funding of sprints to accomplish time-based development goals.

"While conferences and sprints can be a clever way to spend money without sacrificing the voluntary nature of development projects, it is worth keeping one important caveat in mind. When a project selects people for funded attendance at the expense of others, it demonstrates favoritism that can be divisive. In the process of organizing these events, it is important to '''maintain a high degree of transparency and fairness'''. Organizers should use published and fair criteria to determine conference funded attendance and leave attendance open to all. Good criteria for fair selection includes "first come, first served," constructive activity on mailing lists, the number of important commits to a source code or documentation repository, or a good reputation among fellow developers (e.g., as determined by a fair and representative committee)."

==Need for a Full-time Educator==
Sugarlabs should acquire funding to hire a
full-time field-educator to manage communication b/w developers and
teachers. This is really critical to make sure that Sugar meets "felt
needs" of teachers in the developing world rather than perceived needs.
This person would also manager feedback on activities and requests from
the deployments.

It is really critical that this person be an experienced teacher who has
worked full-time at the primary or secondary level, ideally in a
developing country.

An education Ph D from Harvard or MIT would be the wrong person. Those
folks tend to focus on policy and theory, and tend not to have teaching
experience in public schools. We need someone who is thinking about the
problems of teaching long division in a constructionist way and the
basic English grammar.

[[User:BryanWB|BryanWB]] 03:01, 29 May 2008 (UTC)

[[Category:General public]]

==Funding FOSS Projects to Increase Participation==

Mako's essay (http://mako.cc/writing/funding_volunteers/funding_volunteers.html) identifies the negative impacts of paid labor in free software projects. While I concur with his observations, I also feel that paid labor can not only be beneficial but essential in certain situations. This seemingly dichotomous statement becomes quite consistent when we introduce another variable to the argument. This variable is the “scope of the community.” If we are to consider a bigger universe of the community – a universe that encompasses the lesser developed regions of the world – then each of the risk factor has to be re-examined within the context of its scope. The statement “when it comes to voluntary work and paid labor, you can have one or the other but not both” should thus be extended to say that “In a given scope, when it comes to voluntary work and paid labor, you can have one or the other but not both.“ Let us first examine the need for paid labor.

In most voluntary free software projects there is little or no contribution from lesser developed countries. In developing countries there is a general lack of awareness about the benefits of and the opportunities for volunteering. Two basic reasons stand out: (1) programmers do not have the necessary skill sets to contribute; and (2) the economic conditions make part-time employment more attractive than volunteering. Therefore, if the process is left to natural growth there will continue to be a disproportionately lower share of participation from the developing countries. This will not only exclude a large segment of the population, but it will also starve the project from the diversity of solutions that may be necessary to cater to the different social and educational environments of other countries. Therefore, explicit intervention is required.

The intervention could be in the form of setting up focused teams in various regions, which would be funded for a limited period of time. During this period the team would develop capacity by participation in the project and create a FOSS culture in that region. The team would move towards self sustainability by generating revenue from services, and as a by product, create economic opportunities for other participants. This would create an ecosystem around FOSS in the developing world. The definition of capacity building, as envisioned in Mako's essay, would be expanded to include the training of the team members; a core team of developers would have to be paid for a limited duration.

Now let us examine why such a set up would not perturb the dynamics of the project. For example, if we revisit the negative fall outs of paid development in the X Consortium, it can be seen that root cause was that the paid group had significant weight – both in influencing the direction of the project as well as the output they produced. As the offshore teams would be striving to come at par with the mainstream community it is unlikely that they would produce the negative impacts.

I am glad that Mako concluded his essay with the sentence, “Done critically, creatively, and transparently, voluntary free software projects can use money and paid labor to a tremendous benefit that only magnifies their accomplishments.” I think it is important to explore mechanisms for expanding the reach of FOSS development in the developing world; paid labor may well be one such mechanism.

- Tariq, Sep 8, 2008

Sugar Labs/Funding

2008-09-08T17:27:06Z

Tbadsha:

Talk:Sugar Labs/Governance

2008-08-02T16:06:43Z

Tbadsha: /* Decision Panels */

==Other examples==

Please list links to other OSS projects governance documents that may serve as examples of what to do (or what not to do)

===OSS Governance documents===
*http://foundation.gnome.org/about/
*

===Books discussing OSS projects===

Links to books (articles) that may make interesting background reading

*http://producingoss.com/
**Karl Fogel, who has worked on the development teams of CVS, GNU Emacs and Subversion, and is also the writer of “Open Source Development with CVS”—has introduced an extremely comprehensive project guide that will change the way people begin and think about open source projects.

*http://www.dreamingincode.com/
**Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software. The story of Mitch Kapor's Chandler project.

== Document length ==
This is a pretty long and complex document for a first pass at governance of a small project. Most of the details (of becoming a member, having specific committees, or contributing as an organization) could more simply be left on their own pages, and the core gov documents reduced to a few dozen lines. [[User:Sj|+sj]] [[User Talk:Sj|<font color="#ff6996">+</font>]] 03:50, 11 June 2008 (UTC)

:I've moved some of the details to subpages. --[[User:Walter|Walter]] 16:43, 12 June 2008 (UTC)

== Decision Panels ==

This seems to be the most controversial topic:

'''One the one hand:'''

As the instigator of this Decision Panel business, I should attempt to
clarify the idea. My goal is to make serving on the Oversight Board as
unappealing as possible. Ideally, it should be _difficult_ to find seven
people willing to serve on the Oversight Board. As such, the document
specifies that members of the Oversight Board _cannot_ decide
controversial issues. It also specifies that members of the Oversight
Board _must_ act as secretaries, taking minutes for every meeting of every
committee. Oversight Board members are also prohibited from voting in any
of the committee meetings, even though they must attend to take minutes
(that's been part of the draft from the beginning). I hope this will be a
very frustrating experience for members of the Oversight Board.

I am a firm believer that the worst people to give power are those who
want it. The Oversight Board, as described so far, has the responsibility
of keeping Sugar Labs running smoothly, but almost no power to decide the
interesting issues. This makes me very happy, as the Oversight Board is
therefore most likely to attract people who are interested only in keeping
Sugar Labs running, not pushing a particular personal agenda, even a
technical agenda. My hope is that people will be elected based on a
history of being calm, focused, personable, and reasonable, not on the
basis of any platform (they don't have the power to execute it) or
technical knowledge (they can't use it).

I would much rather keep the technical experts _out_ of governance until a
technical decision must be made that requires domain-specific expert
knowledge. Most technical decisions should be made on the mailing lists
anyway; only issues that must be decided in order for work to continue,
and on which the community is otherwise deadlocked, should be escalated to
a Decision Panel. I expect the Oversight Board to be concerned almost
exclusively with the mundane details of managing finances and
partnerships, making sure the communications channels are open, etc. I do
not want the Oversight Board to be a Court of Last Resort.

I still favor the presence of the Decision Panels section in the draft,
but that's not surprising. I see it as an easy lightweight system for
moving political issues away from the Oversight Board. I welcome other
perspectives.

--Ben

'''On the other hand:'''

Why would anyone volunteer for such service? We'd get what it
encourages: unmotivated people who don't really care, except for the
political power of appointing people, and the *inevitable* recognition
they get as part of the oversight board. They won't have the respect of
the community either; as written, board members can't serve on decision
panels, and therefore can't make any of the "important decisions",
presuming the board actually follows the bylaws and appoints a decision
panel. And it has a built in disincentive for creating committees and
delegating (something we want to encourage, not discourage): the
requirement that the board members act as secretaries, causing a yet
larger time sink by board members.

The board member can hide behind "the appointed committee" and absolve
themselves of blame.

So this separates authority from responsibility. Anything controversial
is by its nature something where each vote a board member makes can be
held accountable for, and either recalled immediately or voted out at
the next election, if appropriate. Hopefully these votes occur very
seldom; decisions should normally be being made below the board level,
and the board only have to resolve disputes where the call is close.
"The buck stops here" needs to be true for the board.

It's hard enough to get people to do the grunt work to serve on boards
in these projects. You want the right people who are fully invested in
that project's success. We have to have some confidence that the
electorate will elect sane people: I point to Gnome being sensible
enough to *not* elect RMS to its board (he ran several years), and the
fact that on the X.org board, we had trouble to get enough good
candidates to get some of the people off the board who were *not*
serving for the right reasons (in my opinion).

--Jim

'''Feedback and views:'''

Ben has identified some very good points about not giving power to those who are seeking it (.. and thus likely to abuse it). However, I agree with Jim that the Board cannot be relegated to do secretarial work. The process of selecting board members should be transparent, and as democratic as possible, but once in place it should be trusted to make substantial decisions - of course with the checks and balances (like the referendum on controversial issues.) I like the point Jim makes about accountability. I think the Board should have some dedicated full time support staff to help with the routine work. Admitted that in such voluntary-community projects paying for services is an issue but at the same time we should not be utilizing high powered resources for something that can be done by a less experienced person who is willing to do it as a job but not exciting enough to volunteer for.

--Tariq

== Membership ==

I think that GNOME's membership criteria that you've borrowed here is a
bit lower than I like. In Ubuntu, we use "significant and sustained"
which basically boils down to having been around for at least a couple
months and being able to get at least 2-3 endorsements from current
members that say, "yeah, she's done quite a bit of good work." This is
good because it makes membership more likely to be real stakeholders and
also creates an incentive to long-term significant contributions.

I also like the idea of automatic expiration each year. If folks can't
be bothered to at least reply to an email once a year (you'd be surprised
how often this happens in Ubuntu) they probably shouldn't be voting
either.

--Mako

I don't mind having tougher criteria for developers, but unlike Gnome,
I think we need some way to get participation from users, e.g.,
classroom teachers in deployments, etc. To me, that is significant and
sustained.

--[[User:Walter|Walter]] 16:53, 12 June 2008 (UTC)

Absolutely. There are lots of ways of contributing constructively and
each should be recognized. I'm suggesting that there should be a common
contribution threshold for membership -- whether it's software
developers, content producers, teachers, whatever else, or any
combination.

--Mako

== Other open details ==
* how the governance document is modified; what determines quorum for such actions
:through the referendum process
* how decisions are appealed
:through the ombundman's office, direct communication to the committee or panel, and through the referendum process
* how notice is given of decisions
:Email and posting of minutes in the wiki
* how do we adopt permanent governance regulations; as these currently are, they can at best be temporary until a membership exists and ratifies a more formal governance document...
:We need to have a ratification process--Referendum #1
* what to do about removing/recalling members/board members; it is the board that matters most here).
* how vacancies are filled
* limits on board membership by employer
* how money is disbursed.

== feedback from SFC ==

;Note: Is this requirement too stringent to maintain? Consider making the required meeting frequency lower and say instead: The Oversight Board shall meet at least quarterly/monthly to discuss various topics pertaining to the regular activities of the Sugar Labs Project and Sugar. The Oversight Board expects to meet twice per month.
::Seems to make sense. Quarterly is probably a good steady-state to aim for.

;Note: Should the oversight board be able review/ratify the decision? The way this section is written now, the people elected by the members are not able to actively participate in the decision-making process. Why not allow the board to participate or at least ratify the final decision?
::A ratification process seems reasonable, especially in light of having a mechanism (below) to override the decision.

;Note: should the advisory board be allowed to listen in (perhaps but not participate in) the board meetings or otherwise be allowed to elect a representative for participation (voting or nonvoting) in the Oversight Board meetings? Should they have their own schedule/procedure for meetings?
::Seems to make sense. And their input would be of value.

;Note: as with the advisory committee, should we provide some formal way for the SIGs to provide input? For example, SIGs could have representation on the advisory committee or listen in on board meetings.
::Ditto.

;Note: is there an officially list already? Who gets to add contributors and are they ever removed? Is the Membership and Election Committee another committee of the Oversight Board without any voting members from the OB?
::We need to bootstrap this. It seems a natural place to start is with contributors to Sugar, activity developers, and people active in the wiki and lists.

;Note: can the membership override the Oversight Board under certain circumstance? For example, a 75% vote of all of the members?
::Seems to go hand-in-hand with the idea of the OB ratification process.