Evaluate GrimoireLab for open source community metrics about tasks HOT 11 CLOSED

@jwflory I pulled those specs from the recommendations in their README. I suspect once you begin hooking it up and pulling data into it, it will begin using significantly more resources

from tasks.

Next steps for this task is to set up a new DigitalOcean droplet in the FOSS@MAGIC account. @Nolski and I briefly chatted about trying to build a dashboard for the RIT FOSS community as a proof-of-concept (check out some of the available data sources for ideas on what we can represent).

Once we have a hosted instance up, we should start looking at the visualization tools at our disposal, do a cross-sectional review of our resources, and figure out ways we could build reproducible dashboards for visualizing the different key components we measure in our existing resources.

from tasks.

One thing that has me a bit worried about whether we can host this on a free/cheap service is the reasonably high hardware requirements to run Grimore Lab.

Hardware: 2 CPUs, 8GB memory RAM and enough virtual memory for Elasticsearch

from tasks.

from tasks.

@itprofjacobs If we could have a dedicated VM with 2 CPUs and 16GB of RAM that would be amazing :) Just FYI, that's quite a bit of pricy hardware. To get that on Digital Ocean, it would be around $90/month...

from tasks.

from tasks.

@Nolski Do you have a source on those numbers? I was curious. I ran their full-stack container image and benchmarked it at about ~4GB of RAM usage with a fresh install.

References:

• Grimoire docs: Deploying from DockerHub
• Docker Hub: grimoirelab/full

from tasks.

Discussed in a planning meeting with @Tjzabel on 2019-11-14.

Next action steps

• Research-planning meeting: Wed, 20 Nov.

Notes

Some notes I typed up previously were lost, here was our whiteboard:

from tasks.

Discussed in a planning meeting with @Tjzabel and @Nolski on 2019-11-20.

Summary

Backtracked to requirements planning. We spent a lot of time back and forth on architecture and infrastructure. But before we spend time on technology, we haven't figured out how we will measure our success in whatever we do. So we spent some time to identify some goals, the success criteria for those goals, and what our next steps are to push things forward.

Grimoire components / architecture

Noting this here as a reference:

LibreCorps and Grimoire: What are the value-adds?

1. Tracking of partner projects through a visual dashboard.

• Grimoire allows us to do this in a pre-packaged way that is easy to manage.
• It is supported without a lot of manual work.

2. Evaluating change over time.

• Grimoire allows us to look at non-technical components of an open source community and monitor changes over time.
• This gives immediate feedback if our targeted efforts in supporting teams is being received.

3. Provide insight into the wider Humanitarian Open Source community (either internal or external to an organization).

4. Provide insight into the FOSS@RIT open source community.

What does success criteria look like for each of these value-adds?

1. Tracking of partner projects through a visual dashboard.

• Quick navigation across different organizations, filtered down to cohorts, filtered down to teams.
  Identify specific success stories.
• Compare specific teams (heros vs. slackers).

2. Evaluating change over time.

• Ability to see a range of different platforms used by a team and where they engage the most in the open.
• Provide specific references to what is working and what isn’t.
• Make better (personalized) predictions for project timelines.

3. Provide insight into the wider Humanitarian Open Source community (either internal or external to an organization).

• Easy understanding to see how different projects within an organization relate to each other.
• Discover new opportunities for collaboration across organizations or team in similar areas.

4. Provide insight into the FOSS@RIT open source community.

• Easy understanding to see intake of new community members (How many new members? Are we growing?)
• Identification of key contributors.
• Distinguish between multiple levels of engagement / participation.
• What do current interactions look like? (e.g. GitHub/GitLab, Slack, IRC, maybe Discourse)
• Monitoring of open source content tagged or affiliated with RIT on existing popular platforms (e.g. GitHub topic tags “RIT” “Rochester…”)
  • Helpful to discover where our FOSS support points on campus to help rep the Flag

Next steps

• @jwflory @Tjzabel @Nolski Read up on the overall architecture / components of GrimoireLab over Thanksgiving
• Is it better to use a big image or split it up? This affects how we request resources and plan for the future.
  • Come ready to diagram architecture at next meeting (Wednesday, 4 December @ 10:00)

Other research questions to consider

1. Is the full Grimoire DockerHub image production-ready?
2. How do we manage backups?
3. Explore Ansible automation possibilities with FOSSRIT/infrastructure?
4. How viable is Podman? (rootless containers ftw)

from tasks.

Included in 2020-03-24 issue triage and cleanup.

At CHAOSScon, I discovered Cauldron, a hosted Grimoire dashboard. This seems closely aligned to what we want. I posted a thread on the FOSS@RIT Discourse showing off ten years of FOSS@RIT:

https://fossrit.community/t/10-years-of-foss-rit-3m-lines-of-code-374-contributors-476-prs/190

Since I did that, I haven't had a chance to touch this again. It's on my radar as part of my independent study with @ritjoe though. Keeping this open for now.

from tasks.

Cauldron is sufficient for most of our needs. I'm not going to have an opportunity to finish this before I officially depart RIT though. Closing as wontfix.

from tasks.