Community Archictecture Analysis: Team Proposal

blog › hfoss
analysis, architecture, class, documentation, open-source
Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.

Team Proposal

This blog post serves as a proposal for the community architecture analysis of KDEvelop.

Team Members

Project

Our team is performing an analysis on the community architecture of the KDEvelop IDE.

KDevelop is a cross-platform, multi-language IDE, with a wide variety of integrations. It supports plugins to add more functionality seamlessly.

Division of Labor

Each team member is responsible for a different ‘slice’ of the analysis.

Nic Hartley

Nic is responsible for running Git By a Bus on the repository and answering questions related to the project’s survivability in the event the top 20% of active contributors were unable to continue development.

This includes the following questions:

  1. 6E - Who has the highest amounts of “Unique Knowledge?” (As per your “Git-by-a-bus” report. If there is a tie, list each contributor, with links if possible).

  2. 6J - What have been some of the major bugs/problems/issues that have arisen during development? Who is responsible for quality control and bug repair?

  3. 6K - How is the project’s participation trending and why?

  4. 6L - In your opinion, does the project pass “The Raptor Test?” (i.e. Would the project survive if the BDFL, or most active contributor were eaten by a Velociraptor?) Why or why not?

  5. 6M - In your opinion, would the project survive if the core team, or most active 20% of contributors, were hit by a bus? Why or why not?

Joshua Schenk

Joshua is responsible for calculating the Callaway Coefficient of Fail and answering questions regarding the structure and decision-making process of the community.

This includes the following questions:

  1. 6F - What is your project’s “Calloway Coefficient of Fail?”

  2. 6G - Has there been any turnover in the Core Team? (i.e. has the same top 20% of contributors stayed the same over time? If not, how has it changed?)

  3. 6H - Does the project have a BDFL, or Lead Developer? (BDFL == Benevolent Dictator for Life) If not, what is the structure of its leadership, and how is it chosen?

  4. 6I - Are the front and back end developers the same people? What is the proportion of each?

  5. 6Q - Based on these answers, how would you describe the decision making structure/process of this group? Is it hierarchical, consensus building, ruled by a small group, barely contained chaos, or ruled by a single or pair of individuals?

Ian Effendi

Ian is responsible for the utilizing the alternative analysis tool (in this case, the ‘Openness Rating’ tool provided by OSS Watch) and answering biographical questions regarding the project.

This includes answering the following questions:

  1. 6A - Write a description of the project, its purpose and goals.

  2. 6B - Give a brief history of the project. When was the initial commit? The latest commit?

  3. 6C - Who approves patches? How many people?

  4. 6D - Who has commit access, or has had patches accepted? How many total?

  5. 6N - Does the project have an official “on-boarding” process in place? (new contributor guides, quickstarts, communication leads who focus specifically on newbies, etc…)

  6. 6O - Does the project have Documentation available? How extensive is it? Does it include code examples?

  7. 6P - If you were going to contribute to this project, but ran into trouble or hit blockers, who would you contact, and how?

The source code can be found at KDEvelop’s GitHub Repository.

How will you communicate with them? (i.e. IRC Channel, Email Address, mail lists, issue trackers, etc…)

KDEvelop uses the #kdevelop channel on Freenode IRC.
The project mailing list can be found here: https://mail.kde.org/mailman/listinfo/kdevelop-devel

Upstream / Contributor Mentors

Several team members are listed on KDEvelop’s website here, including inactive developers. Below is the information for the core and active contributors.

Core Developers

  • Kevin Funk | kfunk@kde.org

  • Co-maintainer; C++/Clang, General Improvements, QA, Windows Support, Performance, Website, and more…

  • Sven Brauch | svenbrauch@gmail.com

  • Co-Maintainer; Python Support, User Interface improvements

  • Milian Wolff | mail@milianw.de

  • Generic manager, Webdevelopment Plugins, Snippets, Bugfixing, Performance, and more…

  • Aleix Pol Gonzalez | aleixpol@gmail.com

  • CMake Support, Run Support, Kross Support, Git Support, and more…

Active Contributors

On Challenges

What are the easy parts?

  • Finding the biographical information regarding the project is just a matter of searching for answers in the right places.

  • Since KDE supports the development of KDEvelop, it’s easier to find documentation for the community in one place.

  • Divvying up the work should be ‘easy’ because the rubric establishes all of the things that must be done; it’s just a matter of assigning tasks to each participant.

What are the hard parts?

  • Getting into contact with ‘upstream Mentors’. Time zones and online availability are factors that can impact the process.

  • Large projects will take a longer time to analyze. Knowing the exact process to contribute may take more time to

  • Keeping in communication with team members while working on the analysis itself can be difficult.

How will you overcome both?

By Tuesday, we seek to complete the task distribution and team proposal documents.

By Wednesday, we seek to complete each of our analyses and discuss our conclusions for each of the answers.

By Thursday, we’ll take our individual write-up and put together a presentation to showcase in class on Friday.

On Friday, we’ll present our findings.