MWStake incorporation: Difference between revisions
Bryandamon (talk | contribs) (Placeholder) |
Bryandamon (talk | contribs) (Added Frank and Lex's thoughts.) |
||
Line 1: | Line 1: | ||
Add a header with your name and incorporation ideas: | Add a header with your name and incorporation ideas: | ||
==Frank Taylor== | |||
The questions of mission and membership will influence our choice of a form of incorporation or another manner of organization for the MediaWiki Stakeholders (MWStake). Our discussions so far have revealed that the participants have diverse viewpoints on both questions. | |||
My viewpoint on the question of mission is that we should focus on the needs of third-party users. One of my priorities would be the compilation and publication of best practices. This focus will complement other priorities such as the management of extensions, the eradication of bugs, the coordination of events, and the certification of consultants. | |||
We might include in the bylaws the possibility of expanding the mission of MWStake at some point to include a list of “trusted providers” or a rotation of “on-call” consultants to handle inquiries for providers who are temporarily unavailable. MWStake will need time to formulate processes to manage these functions, however, so we probably should postpone a decision until a later time. | |||
With regard to the question of membership, my suggestion is that we should include in the bylaws the possibility of at least two classes of members such as “users” and “developers” or a similar division of categories. This bifurcation of membership is relevant to points such as voting rights or privileges, the payment of dues, certification programs, and inclusion among the “trusted providers” or “on-call” consultants. | |||
The choices for the form of organization include a nonprofit corporation within the meaning of section 501(c)(3) or section 501(c)(6) of the Internal Revenue Code (IRC) as well as the possibility of a benefit corporation or certification as a B Corp. Our discussions have included a number of points: | |||
* Whether MWStake will generate revenue or perhaps even a profit (my understanding is that nonprofit status does not prevent the generation of revenue) | |||
* The importance of adopting a form of organization that is compatible with the activities of the Wikimedia Foundation and related groups | |||
* The advantages of organizing in a manner that enables MWStake to perform a role distinct from those of other MediaWiki groups | |||
I think that we can develop a consensus on the organization of MWStake as a nonprofit corporation under section 501(c)(6) of the IRC. We will need to tailor the mission and membership accordingly and adopt measures for sufficient governance, oversight, and transparency, but I think that this form of organization will best accommodate our diverse priorities and viewpoints. | |||
==Lex Sulzer== | |||
'''Phase 1''' | |||
# MWStake's mission shall be to support its members in their strategic and daily work to satisfy their customers' requirements. | |||
# MWStake's membership shall stay coherent, efficient and effective. | |||
# MWStake shall dogfeed on its dedication to structured information and structure its addressed aspects e.g. in accordance with [https://smw-cindykate.com/main/File:Enterprise_Knowledge_Management_Roles_Use_Cases_and_Tools_Methodologies.png Enterprise Knowledge Management Roles Use Cases and Tools Methodologies] | |||
# Membership could cost e.g. $100.-/year/vote. | |||
# The money shall be allocated solely to code development projects. | |||
# Potential code development projects are to be sent in to the moderator including user stories to be implemented. | |||
# At monthly MWStake meetings the moderator moderates a discussion on current code development projects addressing corresponding user story priorities and estimated cost. | |||
# Fundable code development projects get voted on. | |||
# Fundable code development projects that get at least 50% of all entitled votes get authorization. | |||
# Authorized code development projects get a single product owner and at least one developer (must not be the same people). | |||
# The single product owner gets remunerated with the equivalent of 3h of development work. | |||
# The developer gets remunerated in accordance with the cost estimation agreed to. |
Revision as of 23:59, 5 July 2018
Add a header with your name and incorporation ideas:
Frank Taylor
The questions of mission and membership will influence our choice of a form of incorporation or another manner of organization for the MediaWiki Stakeholders (MWStake). Our discussions so far have revealed that the participants have diverse viewpoints on both questions.
My viewpoint on the question of mission is that we should focus on the needs of third-party users. One of my priorities would be the compilation and publication of best practices. This focus will complement other priorities such as the management of extensions, the eradication of bugs, the coordination of events, and the certification of consultants.
We might include in the bylaws the possibility of expanding the mission of MWStake at some point to include a list of “trusted providers” or a rotation of “on-call” consultants to handle inquiries for providers who are temporarily unavailable. MWStake will need time to formulate processes to manage these functions, however, so we probably should postpone a decision until a later time.
With regard to the question of membership, my suggestion is that we should include in the bylaws the possibility of at least two classes of members such as “users” and “developers” or a similar division of categories. This bifurcation of membership is relevant to points such as voting rights or privileges, the payment of dues, certification programs, and inclusion among the “trusted providers” or “on-call” consultants.
The choices for the form of organization include a nonprofit corporation within the meaning of section 501(c)(3) or section 501(c)(6) of the Internal Revenue Code (IRC) as well as the possibility of a benefit corporation or certification as a B Corp. Our discussions have included a number of points:
- Whether MWStake will generate revenue or perhaps even a profit (my understanding is that nonprofit status does not prevent the generation of revenue)
- The importance of adopting a form of organization that is compatible with the activities of the Wikimedia Foundation and related groups
- The advantages of organizing in a manner that enables MWStake to perform a role distinct from those of other MediaWiki groups
I think that we can develop a consensus on the organization of MWStake as a nonprofit corporation under section 501(c)(6) of the IRC. We will need to tailor the mission and membership accordingly and adopt measures for sufficient governance, oversight, and transparency, but I think that this form of organization will best accommodate our diverse priorities and viewpoints.
Lex Sulzer
Phase 1
- MWStake's mission shall be to support its members in their strategic and daily work to satisfy their customers' requirements.
- MWStake's membership shall stay coherent, efficient and effective.
- MWStake shall dogfeed on its dedication to structured information and structure its addressed aspects e.g. in accordance with Enterprise Knowledge Management Roles Use Cases and Tools Methodologies
- Membership could cost e.g. $100.-/year/vote.
- The money shall be allocated solely to code development projects.
- Potential code development projects are to be sent in to the moderator including user stories to be implemented.
- At monthly MWStake meetings the moderator moderates a discussion on current code development projects addressing corresponding user story priorities and estimated cost.
- Fundable code development projects get voted on.
- Fundable code development projects that get at least 50% of all entitled votes get authorization.
- Authorized code development projects get a single product owner and at least one developer (must not be the same people).
- The single product owner gets remunerated with the equivalent of 3h of development work.
- The developer gets remunerated in accordance with the cost estimation agreed to.