Please enable JavaScript.
Coggle requires JavaScript to display documents.
Practices (Welcoming newcomers (Provide a newcomer-specific page or portal…
Practices
Welcoming newcomers
Provide a newcomer-specific page or portal guiding their first steps, including architectural information
Provide generation of (semi-)automated documentation filtered to up-to-date information relevant to newcomers
-
Request newcomers to write informative subjective lines when desiring an answer to the community. They should post direct-to-the-point questions
Provide a dictionary to newcomers to facilitate their learning of the technical jargon, acronyms of the community
Point newcomers to easy tasks filtered by difficulty, skills needed, and topics
Inform newcomers about technical background required. Identify which specific technologies they need to know or they should learn to achieve their goal of contributing to the ecosystem
-
-
-
-
-
Meetings and events
-
-
-
-
-
-
Provide several online meetings to discuss architectural problems by IRC, email
-
-
Provide specifics face-to-face meetings with teams of different applications to solve development problems with their interdependent modules
Standardization
-
Require that all infrastructure must be under the control of the ecosystem and be based on the technologies created by the ecosystem.
-
-
Provide code recommendations, defining a standard in the community
-
The organization board defines some technologies that should be used by the whole community as tools for testing, communication, coding review, bugging manager, and navigation
-
Define minimal quality criteria requirements to add an application to the ecosystem (documentation, automatized tests, dependence restrictions)
-
Review and test
-
-
-
-
-
Peer review of changes( In some projects, changes proposed by developers with direct commit rights are also subject to review by other community members)
Test the program(s) produced by the project (Most projects doing repeatable testing do it by defining an automated test suite. If no test suite is available, there may be explicitly defined manual test cases, but this is much less likely to happen. )
During code review, provide feedback information about architecture, good practices to code, doing refactoring and show the best way to solve the problems
-
-
Translation Management
-
-
-
Control the translation work separating artifacts into two groups to translate: stable artifacts have experienced none or few changes and unstable -‐ artifacts are continually being changed and checked constantly.
Provide specific tools to optimize the translation work. For example: the tool, called Localize, searches text to translate and save the specific format. It also suggests words to use in translation.
-
-
Training the members
Provide video-classes about introducing the ecosystem, installing technologies, configuring the development environment, and using the dependencies with other ecosystems
-
-
-
Keep different architects with different levels of specialty to spread the knowledge in the community
Teach experienced members how to use tools to be more productive. For example, the use of shortcut keys, scripts, and plug-‐ins.
Automating
-
-
Provide tools for code optimization, perform static analysis of code, code review, and test automation.
-
-
-
Organizing Architecture
The architect/maintainer taken design decisions to guide the developers considering the communication mechanisms (between systems, between your system and external entities, between elements of your system)
Application architects should follow decisions of the core architects and add their decisions in agreement with their recommendations
Provide autonomy to work on the architecture in accordance with the degree of commitment and experience of work in the community
-
The organization board recommends a tool to create UML diagrams of the architecture to be used by KDE projects
-
Managing mailing lists
-
-
Use tools to support communication in the group such as: mailing lists, forums, IRCs, wikis, blogs to communication.
-
Use discussion mailing lists divided by different topics such as test, development, etc.
-
Managing the Versions
Use of agile practices (continuous delivery, building small versions, frequent releases, and daily meetings)
-
Develop two versions in parallel, an old and a new version until that new version is stable and ready to replace the old version
Release new versions of the product (Release processes in Open Source often include the creation of a number of alpha, beta and release-candidate versions that are delivered by the developers in order to obtain feedback from the community (active users of an OSS system are often willing to test these versions and report about problems they may find). Release processes also often include running a test suite or performing other forms of formal testing.)
Backport corrections in the current release to previous stable releases (When a stable and an unstable (development) branch of a project are maintained simultaneously, so-called backports are often necessary that move corrections or selected improvements made to the development branch into the stable branch.)
Security
-
Provide different levels of security access for the parts of the ecosystems in accordance with the degree of commitment and tasks in the ecosystem
Use tools to publish known cyber security vulnerabilities. For example the Common Vulnerabilities and Exposures (CVE®)
-
-
-
-
Management of the tasks
-
Tag all tasks in accordance with degree of difficulty (easy, medium, difficult)
Each person chooses the work they desire to perform among available tasks in the ecosystem. For example: file to translate, code development, test of applications, and so on.
Provide checklists of tasks to conclude the work. For example: before adding the code to the repository, the developer needs to document, test, integrate with other applications, code must be reviewed by another person and translation must be checked.
Utilizing Tools
Provide a virtual machine with pre-configured build environments, web-based IDEs, or a content management tool
-
-
-
Documentation
-
Provide documentation about translation rules that developers must follow to prepare code for other languages
Provide documentation about operation of projects such as wikis, user guide-‐ lines, and meetings event log.
-
-
-
-
Handling issues
Create a detailed step-by-step tutorial linking information about common problems and possible solutions
-
Report and handle issues with the product (For obvious reasons, this process is present in almost all Open Source projects in some form or another.)
-
Improvement
-
Propose significant enhancements (Some projects have disciplined processes that allow community members to formally propose enhancements for discussion by the community.)
-
-
-
-
-
-