King Arthur, or simply Arthur, is an open source tool designed to schedule Perceval executions at scale through distributed Redis queues. It also provides support to store the data obtained to an ElasticSearch database, thus giving the possibility to connect the results with analysis and/or visualizations tools, such as the Bitergia analytics dashboards.
Nowadays, more and more companies such as PayPal, Bosch or Autodesk are internally implementing inner source programs. Inner source differs from classic open source development process by remaining within the view and control of a single organization and offers many advantages in terms of efficiency and effectiveness.
In previous posts, we talked about Inner source characteristics and advantages such as InnerSourcing: the development model of the future.
Open source projects issues deal with community health and activity: how to get people to contribute or how to keep people engaged are common activities for community managers. Thus, key Performance Indicators (KPIs) should be set for each community based on those goals.
When looking back nowadays to the work done on diversity, I’ve realized that it has been quite a trip! My first approach to the topic was in an informal meeting with Nithya Ruff, currently at Comcast. She mentioned that the OpenStack Summit in Tokyo reached (as far as I remember!) 13% of women attending the Summit. And this was a great number if compared to previous summits as the percentage kept growing. But she also mentioned that they received a tweet asking about the current number of technical contributions. Then this is where we decided to have a look at that issue: have numbers, and try to produce some of them from a quantitative point of view.
Community managers spend their time in numerous community activities related with his/her main role: to get people to talk and contribute, react to the community managed, keep people engaged, etc. Key Performance Indicators (KPIs) should be set for each community based on its goals. It’s part of the job to elaborate reports with multiple metrics on community health for example. But, measuring should be an effective task.
Keeping this in mind, I’d like to share with you 5 reasons about why community managers or any other professional related with software development should have a dashboard that provides all the data about the community or project that she/he manages:
In Bitergia we have a list of happy customers using the Metrics Grimoire toolset (fork them at GitHub!) to produce metrics about their communities. Tracking tech communities is not that simple and this needs of some infrastructure. And one of the main issues usually consists of aggregating all of the information.
While we’re developing and testing our new toolchain for producing Kibana-based software development dashboards, we’re producing a good collection of them, with real data from real projects.
Continue reading “Check our Kibana-based development dashboards!”
Where do the developers in my FOSS community live? For large open source communities where personal contact with developers is impossible, answering this simple question may be difficult. Fortunately, a simple technique, time zone analysis, can be used on git and mailing list repositories to at least partially answer this question. Read our blog post “Using Git and mailing lists time zones to find out where developers live” in OpenSource.com to learn more about it.
As a part of our tests with Kibana and Elasticserch as frontends for our MetricsGrimoire databases, we’ve set up a dashboard for understanding the code review process in OpenStack (be sure of visiting it with a large screen and a reasonable CPU, otherwise your experience may be a bit frustrating).
This dashboard includes information about all review processes (changesets) in OpenStack, using information obtained from their Gerrit instance. For each review, we have information such as the submitter (owner), the time it was first uploaded and accepted or abandoned, the number of patchsets (iterations) needed until it was accepted, and the time until it was merged or abandoned. With all of them we have prepared an active visualization that allows both to understand the big picture and to drill down looking for the details. Follow on reading to learn about some of these details.
[Note: this is our second post about our dashboards based on Kibana. If you’re interested, have a look at the first one, about OpenStack code contributions.]