|
|
| (7 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| − | [[Image:workgroups_development.jpg|right]]
| + | {{archived|30952|Production Working Groups|cat=Working Groups,Development}} |
| − | The collaboration within the Joomla! Open-source project is based upon the trust and fun. We want to put as little hierarchy into this team as possible, and, if we actually do Joomla! (all together) this section will be superfluous. But for every team that exists of more than one person, a structure needs to be in place.
| |
| − | | |
| − | This team sometimes also is referred to as core-committers. Some of the members are also core-team members, but the term "core-comitter" refers to team members who have full commit access to the Joomla! code base.
| |
| − | | |
| − | == Positions, responsibilities and roles ==
| |
| − | | |
| − | The '''Development Workgroup Coordinator''' has the overall lead on Joomla! development and has the following responsibilities:
| |
| − | # Will take care of properly planning the progress through the development stages for the various working groups. Proper planning includes: architectural design, coding stages, testing stages, release stages etc.
| |
| − | # Will take care of basic communication to all surrounding workgroups. Arrange structure for testing and documentation, linking development effort to the other roles of the workgroups.
| |
| − | # Will take care of standards and guidelines that need to be followed within the development workgroups (not writing them myself, but just arrange that these are created).
| |
| − | # Will write a roadmap proposal for the Core team, and in later stages propose it to the community. Process any feedback, but guarding the overall goals of the project.
| |
| − | # Will take care of periodical communication to the community: doing a blog, but also taking the road to the PR workgroup.
| |
| − | #Will define some workgroup membership guidelines, and try to implement them into the workgroups. Non active, or non functional workgroup members can be removed, for this see the "Status" section.
| |
| − | # Will invite new members to the workgroups (can also be done by the lead developers), and remove them when this is needed.
| |
| − | # Will determine which lead developers are in the team.
| |
| − | # Guards the progression on the pre-defined project goals.
| |
| − | | |
| − | A '''Lead Developer''' is a special development '''role''' within the development work group. There is no limit on the number of lead developers but the general rule is, 1 lead developer for every 5-10 developers, and in some occasions one lead developer per specific project goal (such as a main release). A lead developer has the following responsibilities:
| |
| − | # Does architectural design for major and minor releases.
| |
| − | # Does final code review before code gets submitted to the trunk.
| |
| − | # Guards the general integrity of the Joomla! framework in terms of architectural concept implementation, coding standards and documentation.
| |
| − | # Does mentoring of development workgroup members.
| |
| − | # Does development of the Joomla! framework code.
| |
| − | # Does testing.
| |
| − | # Manages the creation of proper technical documentation of the framework (concepts, APIs, etc.).
| |
| − | | |
| − | A '''Developer''' actually performs programming, testing and documentation tasks. A Developer can potentially assign himself to a wide variety of tasks but their individual abilities will likely determine which areas he/she will work on.
| |
| − | # Does development of the Joomla! framework code.
| |
| − | # Does testing.
| |
| − | # Follows [[Development guidelines]].
| |
| − | # Works on technical documentation of all aspects of the Joomla! framework.
| |
| − | | |
| − | == Membership status ==
| |
| − | | |
| − | Within the development work group, we recognize three membership statuses:
| |
| − | # '''Active''' - actively contributing on a week-by-week or day-by-day basis (or even more).
| |
| − | # '''On-leave''' - temporarily away from duties because of vacations, work commitments or other valid reasons but still in touch with regular communication channels.
| |
| − | # '''Inactive''' - Away from duties and responsibilities for a period of time and not in touch with regular communication channels.
| |
| − | | |
| − | A development team group member is considered active if they are contributing to a communication channel at least once a week and fulfilling a reasonable time commitment to the project. To prevent stagnant teams and blocking out new talent from getting into the development work group some limitations apply to the possible statuses described above:
| |
| − | # A development work group member may be on-leave for up to 3 months. After this period the team member will automatically be transferred to inactive status.
| |
| − | # A development work group member may be inactive for up to 6 months. After this period the team member will automatically be removed from the work group. When transferred from on-leave status to inactive, the total period a team member can be absent is 6 months.
| |
| − | | |
| − | In all cases it is important that the developers informs the work group coordinator or lead developer of his team that he/she is (planning to go) on leave or being inactive.
| |
| − | | |
| − | == Conflict resolution ==
| |
| − | | |
| − | It would be naive to assume that a group of people can work together in perfect harmony. There are going to be times when someone feels they have been wronged. In these times the following procedure should apply:
| |
| − | | |
| − | # Talk privately to the person concerned.
| |
| − | # If you still believe grievances exists, then bring in one or two other people to help mediate.
| |
| − | # If this fails then take the issue to the workgroup coordinator.
| |
| − | # If this fails take the issue with the workgroup coordinator to the Joomla! project leader.
| |
| − | # If this fails take the issue to the whole Core team for final determination.
| |
| − | | |
| − | Team members are encouraged to self-mediate all disputes. In all situations, treat 'wounds' appropriately. A prick on the finger just needs a tissue for a couple of seconds. Some grazes and cut just need a Band-Aid to help heal well but will probably heal anyway if left untouched. More serious lacerations need immediate intervention for survival. If a wound is left to attract an infection then the obvious threat of gangrene is present.
| |
| − | | |
| − | == Resignation ==
| |
| − | | |
| − | Everyone in Joomla! has their season and there are going to be times when someone needs to move on for various reasons. You should always feel comfortable to leave or have a holiday from the project, just inform the work group coordinator or better yet, let the whole team know by posting your absence to the mailing list (joomla-devel@googlegroups.com). If you are going to be unavailable for a period of time, please be considerate and:
| |
| − | | |
| − | * Give reasonable notice in proportion to your role. Work group coordinator and Lead Developers should give around four weeks notice and other members at least one.
| |
| − | * Make sure that your team knows what they have to take over when you leave. Do not put the Team in a position where they have to play detective to find out what you did, where things are, and what their status is, etc.
| |
| − | | |
| − | == Removing members ==
| |
| − | | |
| − | A development team member will be removed:
| |
| − | * When he/she violates the Code of Conduct.
| |
| − | * When the work team member is inactive for more then 6 months (see the membership status section above).
| |
| − | | |
| − | [[Category:Development]]
| |
