WIP: Add TEAMS structure to GOVERNANCE #9914
|
@ -1,36 +1,20 @@
|
|||
# Governance
|
||||
|
||||
|
||||
Organic Maps Project (organicmaps.app) is an open-source project.
|
||||
The Organic Maps project is community-driven and has little hierarchy.
|
||||
|
||||
## The Governing Board
|
||||
## [The Board](GOVERNANCE/BOARD.md)
|
||||
Ensures the project stays within its [Mission and Core Values](CORE_VALUES.md),
|
||||
legally hosts project's assets like trademarks, domains, finances etc. and handles legal enquiries.
|
||||
See [details](GOVERNANCE/BOARD.md) of Board's structure and responsibilities.
|
||||
|
||||
The focus of the Governing Board is to assist and guide in the progress and development of Organic Maps, as well as to lead and promote Organic Maps.
|
||||
## [Teams](GOVERNANCE/TEAMS.md)
|
||||
|
||||
The Governing Board is the governing body responsible for the overall oversight of the Organic Maps Project. The Board also has the responsibility to ensure the goals, brands, and marks of Organic Maps and community are protected. The Board serves as the final authority within the Organic Maps Project.
|
||||
Day-to-day work and decisions are made by the teams of active contributors ("the doers") in their area of expertise, e.g. Android development, translations or devops, see [the full list of Teams](GOVERNANCE/TEAMS.md).
|
||||
|
||||
## Governing Board Responsibilities
|
||||
|
||||
- Guidance and leadership over the ultimate Project roadmap.
|
||||
- Community outreach.
|
||||
- Maintenance of health and viability of the community.
|
||||
- Maintenance of a healthy and proactive relationship with the Project users and consider those needs and uses in decisions.
|
||||
- Coordination of Project messaging.
|
||||
- Overall Project leadership as the final escalation point for decisions.
|
||||
- Trademark and brand oversight.
|
||||
- Appointment of Board Chair.
|
||||
- Appointment of new Board members.
|
||||
- Re-appointment of Board members after 12 month term of service.
|
||||
|
||||
## Chair Responsibilities
|
||||
|
||||
- Organize and run the Board meetings.
|
||||
- Be the coordinating and lead voice for the Project.
|
||||
- Coordinate the Board to set direction and articulation thereof.
|
||||
- Focus on helping the Board to reach consensus.
|
||||
- Guide the Board in transparency and practicing the open source way in leadership and decision making.
|
||||
|
||||
## Current Sitting Board
|
||||
|
||||
- [Alexander Borsuk](https://github.com/biodranik)
|
||||
- [Victor Govako](https://github.com/vng)
|
||||
- [Roman Tsisyk](https://github.com/rtsisyk)
|
||||
At the moment there is no formal process to resolve non-technical disputes (e.g. UX disagreements or whether a proposed change fits into OM at all),
|
||||
but there are some common sense guidelines / recommendations:
|
||||
- strive to address all reasonable concerns
|
||||
- ask more contributors and experts on the matter to provide their opinion
|
||||
- refer to users' feedback, e.g. include the change into an alpha version or poll via communication channels
|
||||
- usually an incremental improvement is better than no change at all, create separate issues for follow-up concerns
|
||||
- give benefit of a doubt to the actual "doers" who commit their energy into code, designs, etc.
|
||||
|
|
41
docs/GOVERNANCE/ANDROID_TEAM.md
Normal file
|
@ -0,0 +1,41 @@
|
|||
# Android team
|
||||
|
||||
- Android app development
|
||||
- Feature implementation
|
||||
- Testing and debugging
|
||||
- Performance optimization
|
||||
- Code review
|
||||
|
||||
Together with the [iOS team](IOS_TEAM.md) strive for feature parity and UI/UX consistency across platforms.
|
||||
|
||||
For UI/UX help ask the [Design team](DESIGN_TEAM.md).
|
||||
|
||||
### Active contributors and their permissions
|
||||
- @rtsysik (merger)
|
||||
- @vng (merger)
|
||||
- @biodranik (merger)
|
||||
- @pastk (merger)
|
||||
- @kirylkaveryn (merger)
|
||||
- @redauburn (repo write)
|
||||
- @kavikhalique
|
||||
- @dvdmrtnz
|
||||
- @andrewshkrob (repo write)
|
||||
- @strump (repo write)
|
||||
- @map-per
|
||||
|
||||
![]() I have push permission in case that has any relevance. I have push permission in case that has any relevance.
|
||||
Android Auto developers and testers: @organicmaps/android-auto.
|
||||
|
||||
Ask for technical reviews from @organicmaps/android (also see CODEOWNERS).
|
||||
At least one technical approval is required for a merge.
|
||||
|
||||
Quality assurance:
|
||||
PR authors are expected to test their changes extensively and reviewers to help with it.
|
||||
But we'd love to have some people commited to testing specifically! Add yourself here!
|
||||
|
||||
You don't have to be listed above to submit a PR occasionally, take part in a discussion or do a review.
|
||||
|
||||
If you've been contributing actively for some time then feel free to open a PR to be added into the contributors list.
|
||||
Likewise open a PR/issue to ask for permissions like write access, merge rights or if you want to be added into the technical reviewers:
|
||||
|
||||
### Docs and resources
|
||||
- [Java Style Guide](JAVA_STYLE.md)
|
36
docs/GOVERNANCE/BOARD.md
Normal file
|
@ -0,0 +1,36 @@
|
|||
# Governance
|
||||
|
||||
Organic Maps Project (organicmaps.app) is an open-source project.
|
||||
|
||||
## The Governing Board
|
||||
|
||||
The focus of the Governing Board is to assist and guide in the progress and development of Organic Maps, as well as to lead and promote Organic Maps.
|
||||
|
||||
The Governing Board is the governing body responsible for the overall oversight of the Organic Maps Project. The Board also has the responsibility to ensure the goals, brands, and marks of Organic Maps and community are protected. The Board serves as the final authority within the Organic Maps Project.
|
||||
|
||||
## Governing Board Responsibilities
|
||||
|
||||
- Guidance and leadership over the ultimate Project roadmap.
|
||||
- Community outreach.
|
||||
- Maintenance of health and viability of the community.
|
||||
- Maintenance of a healthy and proactive relationship with the Project users and consider those needs and uses in decisions.
|
||||
- Coordination of Project messaging.
|
||||
- Overall Project leadership as the final escalation point for decisions.
|
||||
- Trademark and brand oversight.
|
||||
- Appointment of Board Chair.
|
||||
- Appointment of new Board members.
|
||||
- Re-appointment of Board members after 12 month term of service.
|
||||
|
||||
## Chair Responsibilities
|
||||
|
||||
- Organize and run the Board meetings.
|
||||
- Be the coordinating and lead voice for the Project.
|
||||
- Coordinate the Board to set direction and articulation thereof.
|
||||
- Focus on helping the Board to reach consensus.
|
||||
- Guide the Board in transparency and practicing the open source way in leadership and decision making.
|
||||
|
||||
## Current Sitting Board
|
||||
|
||||
- [Alexander Borsuk](https://github.com/biodranik)
|
||||
- [Victor Govako](https://github.com/vng)
|
||||
- [Roman Tsisyk](https://github.com/rtsisyk)
|
17
docs/GOVERNANCE/EXPERTS_TEAM.md
Normal file
|
@ -0,0 +1,17 @@
|
|||
# Experts and talent
|
||||
|
||||
An umbrella "team" for pools of subject matter experts and talent in various fields.
|
||||
|
||||
If you need an expert advice in a specific matter like OpenGL, then just tag/mention a relevant group and ask for help.
|
||||
If you're an expert in a certain matter and is willing to help the project by sharing your knowledge occasionally then sign up please!
|
||||
|
||||
Tag one of these if you seek help/advice on specific matters:
|
||||
- @organicmaps/cpp - C++ experts and learners
|
||||
- @organicmaps/privacy - privacy best practicies
|
||||
- @organicmaps/shaders - 3D graphics and shaders experts
|
||||
- @organicmaps/web - web development
|
||||
- @organicmaps/brainstorm - general brainstorming of raw ideas
|
||||
- @organicmaps/legal - legal matters, licenses compliance
|
||||
- @organicmaps/community - community relations, insights into users' feedback and preferences
|
||||
|
||||
Please open an issue/PR to ask to be added into one of the pools above or to create a new one!
|
47
docs/GOVERNANCE/TEAMS.md
Normal file
|
@ -0,0 +1,47 @@
|
|||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
# Teams
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
A team is a group of people who work together on a specific area to further Organic Maps.
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
Team pages list responsibilities, active contributors ("doers") and permissions they hold, as well as links to team-specific docs and resources.
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
Its not necessary to be a part of a team in order to submit a PR, take part in a discussion or otherwise participate in team's work.
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
People listed there are the most active contributors and "go to" persons, so that its clear whom to ask questions, request reviews, etc.
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
They could be trusted with extra permissions and accesses necessary for their work (e.g. merge rights).
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
If you've been contributing actively then feel free to open a PR/issue to add yourself to relevant teams and/or request permissions needed to facilitate your work.
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
rtsisyk
commented
Quick formatting suggestion: how about putting each team under a second-level header (##) so there’s more room for details? Quick formatting suggestion: how about putting each team under a second-level header (##) so there’s more room for details?
pastk
commented
The most of the teams will be just links to relevant team pages with all the details. For now I've added short responsibility lists so that its easier to see if we missed some important bits or not. The most of the teams will be just links to relevant team pages with all the details.
Maybe there could be a short sub-title (like it is now) so that its more clear what the team is about.
For now I've added short responsibility lists so that its easier to see if we missed some important bits or not.
|
||||
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
- RELEASE
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
<br>stores accs, maps generation, alphas/betas
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
- COMMS
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
rtsisyk
commented
Communication? Communication?
pastk
commented
yeap Just like DEVOPS and not DEVELOPER OPERATIONS yeap
I thought a short name sounds more cool :)
Just like DEVOPS and not DEVELOPER OPERATIONS
|
||||
<br>announcements (chats, social media, web site news), moderation
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
- USER SUPPORT
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
<br>feedback in stores, emails, social media, managing issues, user-facing docs (FAQs)
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
- TRANSLATIONS
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
<br>UI strings, store descriptions, rel notes, etc.
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
- DESIGN
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
<br>UI, UX, graphic design, product design
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
- GROWTH and SUSTAINABILITY
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
<br>marketing (SEO/ASO/SMM), user research, fundraising (donations, grants, monetization), attraction, retention and funding of contributors, financial transparency
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
- [EXPERTS](EXPERTS_TEAM.md)
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
<br>subject matter experts and talent in different fields, willing to share their knowledge
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
- [ANDROID](ANDROID_TEAM.md)
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
rtsisyk
commented
Do we need a separate file? Why don't incorporate the description right here? Do we need a separate file? Why don't incorporate the description right here?
pastk
commented
The file will get very big and harder to navigate and manage. The file will get very big and harder to navigate and manage.
|
||||
- IOS
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
- MAPS
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
<br>map data, styles
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
- APP CORE
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
<br>rendering, routing, search, editor, bookmarks & tracks, maps generator, desktop and mobile linux versions, etc.
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
- DEVOPS
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
<br>servers / cdn, CI/CD, tooling
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
||||
- ADMINS
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
rtsisyk
commented
What is the difference with DEVOPS? What is the difference with DEVOPS?
pastk
commented
DEVOPS work on servers, ci, etc and they need relevant permissions and accesses ADMINS assign those permissions to them (as well as to other teams) by following a defined permission request policy/procedure (TBD), if permissions are time-limited (e.g. for a year) then they oversee renewals, etc. if there won't be any permissions policies (like it is now) then there won't be any need in this team :) DEVOPS work on servers, ci, etc and they need relevant permissions and accesses
ADMINS assign those permissions to them (as well as to other teams) by following a defined permission request policy/procedure (TBD), if permissions are time-limited (e.g. for a year) then they oversee renewals, etc.
if there won't be any permissions policies (like it is now) then there won't be any need in this team :)
|
||||
<br>manage individual and team permissions
|
||||
rtsisyk
commented
What about Documentation? Should we include this domain here? What about Documentation? Should we include this domain here?
pastk
commented
user-facing docs like FAQs user-facing docs like FAQs
|
Hey, could we focus on TEAMS.md in this PR so we can move forward with it quickly without getting sidetracked by other topics for now?