DEV Community: Ana Jimenez Santamaria

Leafy Goose: A Human-Led AI Assistant for Maintainers’ Community Work

Ana Jimenez Santamaria — Sun, 01 Nov 2026 15:28:33 +0000

How I built a human-led community assistant with Goose Agent and Skill.md

Every tech community knows this moment: a newcomer joins, says hi, and asks "What should I do first? Please help!" Welcoming one newcomer is easy. Welcoming new people every single week, with the same questions, is a different story.

In a Discord open source community I help with, the same "how do I get started?" questions come back again and again: Do I need to attend every meeting? Where do I share my idea? The answers are already in our guides. But I get it: people want a quick answer in the place where they asked. They don't have time to dig through pages, and they want to feel there is a person on the other side.

Most moderators from this community are volunteers, so those answers sometimes wait days. A bot that answers on its own is not the fix either. It is fast, but it loses the human connection, and it can be wrong. So I kept thinking: how can we answer faster, right where people ask, and still keep a human in the loop?

My answer this time was a build with goose, a SKILL.md and Discord. I started with a small bot called Goose Bot v1 and ended with Leafy Goose 🍃🪿, an open source bot where AI drafts the answer and a human always decides what gets posted.

In this post, I share how I got there, step by step + a link to the public repo at the end to test it yourself with your community

Build the workflow once, reuse it anywhere

I wanted to build a reusable workflow that other trusted community members could help review and maintain. I also wanted to adapt it to other communities I’m involved with by changing the resources goose reads, without touching the code.

That led me to use goose as the AI layer behind the Discord bot. The bot handles the Discord interaction, while goose uses the community’s resources and instructions to draft answers to questions phrased in different ways.

Why goose over a direct API call?

This is a fair question I got from folks who have been following my work. I could have connected the bot directly to a model API. None of the building blocks below is unique to goose, but goose gives me all of them in one open source tool, ready to use:

Provider changes without code changes: the model provider is configured in goose's settings, so switching providers doesn't require editing the bot.
Reusable instructions: the same SKILL.md can be used outside Discord, making the workflow useful beyond the bot (more on this in step 2).
Tools when needed: extensions add capabilities as the workflow grows. For example, a calendar integration could let the bot check when the next community call is scheduled, something I could add in the future.

Today the bot is built for Discord, so other chat tools would need some extra work. But only one part of the architecture would change: the chat layer. The guide, goose and the answer checks can stay the same.

The Architecture

Leafy Goose has one rule: AI drafts, a human publishes. A reviewer (a moderator, maintainer or community manager) picks a member's question. The bot asks goose for a draft, using only the community guide. The reviewer reads the private draft and decides.

Only the prompt goes out to the model provider, and only a reviewer's click puts an answer in a public channel.

Before you start

You need four things:

Node.js 20 or later
goose CLI signed in to a model provider
A Discord app from the Developer Portal
Manage Server permission on your Discord server, so you can add the bot. Only the person who installs it needs this. Other reviewers don't need it (the person who runs the bot adds their Discord user IDs to the settings)

1. The prototype

My first bot was simple. A slash command took the question, sent it to goose, and showed the answer. It worked and taught me fast what can go wrong when a model talks to real people:

Acronyms are ambiguous: the community name is an acronym, and the model at first answered about a popular web framework with the same initials
The model has its own style and that lack of customization was odd in a community channel.
There are old links, meeting times, channels that are private that the model cannot tell which facts are still true unless you give them proper instructions

Each of these became one rule in the next version

2. One guide, one source of truth

All the facts live in one Markdown file: the community guide. Changing what the bot says means editing that file, not the code.

The guide has a few simple rules:

Public information only. The bot may quote anything in it, so no passwords, private links or personal data.
A Last reviewed: <date> line. Drafts show a warning when the guide is older than 30 days.
Every link in the guide is an approved link, and every <#channel> mention is an approved public channel. The bot builds its allowlists from this file (more on that in step 5).

At first it was a plain .md file. Later I turned it into a goose skill, so the same guide could also works beyond the bot if more people want to make use of it (more in the side story below).

---
name: drf-community-guide
description: "Approved facts, links and public Discord channels for the community. Use it to draft answers about getting started, community calls, events, contributing and conduct."
---
...

Plain .md vs SKILL.md

With a plain .md, an agent does not know the file exists: you have to paste it or ask the agent to read it every time. A skill is found automatically: the agent sees its name and description in every session, and loads the full guide only when a question matches or when you ask for it.

So why does the bot not load it as a skill? goose loads a skill only when it decides the question matches the description. For a bot that must always stay on facts, "maybe" is not good enough. The bot reads the file itself, removes the top block, and puts the whole guide in every prompt

🪿 Side story: a skill beyond the bot. Because the guide is a standard SKILL.md, it is useful outside Discord too. Community managers, moderators, or anyone curious about the community can add it to their favorite AI agent (goose, or any other agent that supports skills). Then they can ask it for help with a welcome post, an answer in GitHub Discussions or a newsletter. Same facts and links, wherever they work.

3. Keeping a human-review in every answer

This is the heart of Leafy Goose. Every answer starts as an ephemeral message: only the reviewer who asked can see it. Under the draft there are three buttons: Publish, Edit and Discard.

A reviewer can start a draft by right-click a member's message, then Apps, then Answer with Leafy Goose

Discord wants a first response within 3 seconds, and goose needs longer. So the bot defers the reply first, then asks goose:

async function createDraft(interaction, question, target) {
  // ...allowlist, cooldown and "one request at a time" checks...
  await interaction.deferReply({ flags: MessageFlags.Ephemeral });
  const raw = await guideLib.askGoose(guide, question, { timeoutMs: GOOSE_TIMEOUT_MS });
  const result = guideLib.checkAnswer(raw, guide);

  if (!result.answer) {
    return interaction.editReply(
      `🤔 Leafy Goose has no approved answer for this (${result.noAnswerReason}).`);
  }

  const id = interaction.id;
  drafts.set(id, {
    id, answer: result.answer, warnings: result.warnings,
    reviewerId: interaction.user.id, interaction, target,
    timer: setTimeout(() => expireDraft(id), DRAFT_TTL_MS), // 14 minutes
  });
  await interaction.editReply({ content: renderDraft(...), components: draftButtons(id) });
}

Drafts expire after 14 minutes, because Discord interaction tokens last 15.

This is what a reviewer sees. Only they can read it:

When the reviewer clicks Publish, the bot replies to the member's message when there is one. That way the answer stays next to the question:

const channel = await interaction.client.channels.fetch(draft.interaction.channelId);
if (draft.target) {
  const message = await channel.messages.fetch(draft.target.messageId);
  sent = await message.reply(options); 
} else {
  sent = await channel.send(options); 
}

A few small details that matter in a real community:

The draft is deleted from memory before posting, so a double click cannot post twice.
Only the reviewer who made a draft can press its buttons or open its edit form.
allowedMentions blocks @everyone, @here and role pings. Only the member being answered is mentioned.
Link previews are off, so one answer does not fill the channel with cards.
Every published answer ends with a small footer: AI-assisted answer, reviewed by @reviewer.

4. Running Goose

goose is an agent: with extensions it can run shell commands and read files. For a Discord bot I want the opposite. goose should read one prompt and write one answer, nothing more.

The bot calls the goose CLI with execFile (no shell) and four flags:

const args = [
  "run",
  "--no-session",  
  "--no-profile",   
  "--quiet",        
  "--max-turns", "2",
  "--text", buildPrompt(guide, question),
];

await execFileAsync(process.env.GOOSE_BIN || "goose", args, {
  timeout: timeoutMs,
  env: safeGooseEnv(),
});

safeGooseEnv() does two jobs. It sets GOOSE_MODE=chat, so goose does not call tools. And it removes every DISCORD_* variable, so the Discord token never reaches goose:

function safeGooseEnv() {
  const env = { ...process.env, GOOSE_MODE: "chat" };
  for (const key of Object.keys(env)) {
    if (key.startsWith("DISCORD_")) delete env[key];
  }
  return env;
}

The prompt has two clearly marked parts: the guide, which the bot trusts, and the member's message, which it doesn't. Member text could try a prompt injection to ignore the rules, reveal the prompt or act as something else. No single trick stops that, so the bot uses layers:

It escapes every < and > in the message, so it can't close its marker and pretend to be part of the guide (code below)
The prompt tells goose to treat the message as untrusted and to reply NO_ANSWER: off-topic request to these attempts
A human reviews every draft before anything is posted

function cleanQuestion(question) {
  return question
    .replace(/</g, "&lt;")
    .replace(/>/g, "&gt;")
    .replace(/\s+/g, " ")
    .trim()
    .slice(0, MAX_QUESTION_CHARS); 
}

The prompt rules are short and strict: always English, at most 120 words, one clear next step, only links from the guide, never a date for a future meeting. When the guide has no answer, the model replies with one line: NO_ANSWER: <reason>. The bot then tells the reviewer to answer by hand, instead of guessing.

💡 Watch your error logs: One of the things I did to avoid leaking members' questions was to never log goose's raw error. When goose fails, Node's error repeats the full command, question included. Leafy Goose only reports goose failed (exit code 1).

Before a draft reaches the reviewer, the bot also flags links or channels that are not in the guide, meta comments and very long answers.

6. Tests

There are two kinds of tests in the repo, and they answer different questions:

Unit tests check the code: is the guide loaded? are bad links flagged? do Discord secrets stay out of the goose environment? They use a fake guide and goose script, so they need no Discord, no goose and no network
Evals check the answers: Each eval is a real question, plus words the answer must or must not contain:

{ "question": "how can i contribuite to drf",
  "mustInclude": ["touchpoint"],
  "mustNotInclude": ["if you mean", "contribuite"] }

This one checks two things. The answer points to a community call, and the bot does not comment on the member's typo. Other evals check that the bot never invents a date, never links a private channel, answers in English, and replies NO_ANSWER to off-topic questions and injection attempts.

7. Set it up for your community

Leafy Goose started as a bot for one community, but nothing in the code is specific to it. To use it in another Discord community, you write a new guide, change a few settings and update your own .env

One running bot serves all your reviewers: add their Discord user IDs to DISCORD_ALLOWED_USER_ID. The code is at github.com/anajsana/leafy-goose

Final remarks

As a maintainer in open source communities, I know the community load first-hand, and there is still a lot of talk about AI adding to maintainer burnout. However, this time, with Leafy Goose, I wanted to show the other side: the side where AI can take on the repetitive and boring part of community work, while maintainers keep the voice, the judgment and the human connection.

I also wanted another community manager to be able to take this, point goose to their own community's guide, and review the answers without having to rebuild the Discord bot. If you try it in your community, I'd love to hear how it goes! 👋

Faster Model, Better Agent? Training Efficient AI Agents

Ana Jimenez Santamaria — Mon, 26 Oct 2026 17:27:20 +0000

Notes from PyTorch Meetups Madrid, and what OpenEnv means for engineering teams

The first-ever PyTorch Meetup Madrid was last week! Ricardo Noriega (PyTorch Foundation Ambassador) and I (AAIF Ambassador) opened the event, after us, Carlos Camacho (Red Hat) talked about serving agents at scale wiht d-llm, and Sergio Paniego Blanco (Hugging Face) talked about training them wiht OpenEnv.

Note: While I'd love to write a full post about all the meetup discussions and sessions, this one will focus on the OpenEnv presentation. You can watch the full recording here.

A small model that solved more tasks and used fewer tools

I came home thinking about one result from Sergio's talk: a cool experiment where a small model, after training, solved more tasks and used fewer tools to do it. Most conversations I hear about agents are about which model is fastest, but this one was about how much work the agent does before it finishes.

The training setup used OpenEnv, which has just joined the Agentic AI Foundation (AAIF). I didn't really understand the value OpenEnv could bring before the meetup, but I ended up testing it myself after the session. This post is a short intro to OpenEnv and how it connects with the broader ecosystem, such as MCP and Goose.

Training an agent is different from training a model

Ask a coding agent to fix a bug. It reads a file, edits it, runs the tests, sees a failure and tries again. Writing code that looks right is only part of the job. The rest is deciding what to do after each result.

Sergio covered three ways to train for that: learning from recordings of agents doing the task (supervised fine-tuning), learning from a stronger teacher model (distillation), and learning from scores on the model's own attempts (reinforcement learning). Hugging Face's post-training curriculum explains all three.

The third one needs somewhere for the model to practice. That's an environment.

So, what is OpenEnv exactly?

In practice, an OpenEnv environment is like a small server, usually running in a Docker container. Inside it you put three things:

The task: for example, fixing a bug in a Python function that should apply a discount to a shopping basket total (but doesn't)
The tools the agent can use: like reading a file, editing it and running the tests.
The code that checks the result and gives a score.

Your agent sits outside and talks to it through three calls: reset() to start a new attempt, step() to take an action, and state() to see where things are.

obs = env.reset()
obs = env.step(CallToolAction(tool_name="run_tests", arguments={}))
print(obs.reward, obs.done)

OpenEnv doesn't decide what counts as a good answer (you write that). What it gives you is a standard shape, so the same environment works with different agents and different training libraries, like Hugging Face's TRL.

How can an environment like OpenEnv help with agentic AI adoption?

With everything we've seen so far, you might be thinking: "OK, but my team doesn't train models" (and most of the teams, don't!) The good news is you can still use an environment to test and measure your agents.

And that matters, because many teams are stuck between a prototype or demo and a production-ready agent they can trust. Last year, Gartner predicted that over 40% of agentic AI projects will be canceled by the end of 2027, because of rising costs, unclear business value or weak risk controls.

Here's how an environment can help with three of the most common challenges engineering teams face.

Measurement: "Is our agent actually good at our tasks?"

In LangChain's survey of more than 1,300 professionals, only about 52% of teams run evaluations, while nearly 89% have observability. In other words, most teams can see what their agent did, but fewer can tell if it did it well.

With an environment, you get numbers: how many tasks the agent solved and how many steps it needed, across different models and providers. It works like a test suite, but for your agent.

Note: Over three-quarters of organizations use more than one model in production or development. Maybe you want a cheaper model, a local one, or the new release everyone is talking about. Today most teams try it for a few days and go by feel.

Cost and speed: "Our agent gets there, but it takes forever"

Every extra tool call costs time, tokens and money. Sergio's result is about exactly this. In his experiment, LFM2.5-2.6B went from solving about 42% to 54% of tasks it had never seen, averaged across four harnesses. On tasks the base model already solved, it used 31% fewer tool calls. And while fewer calls and fewer tokens aren't the same thing, it shows that efficiency can be measured and improved, not only the final answer. Even before any training, an environment records every step, so you can see where your agent wastes time.

Risk: "We can't let an agent experiment on our real systems"

Part of the problem is that the only way to really know how an agent behaves is to let it act. And nobody wants it learning on the production side, right?

An environment can be a safe copy: a fake calendar, a copy of a repo, a test database. The agent can fail as many times as it needs without touching anything real.

A real example: Turing built Calendar Gym on OpenEnv to test how agents schedule meetings: which calendar to use, what they have permission to change, and which actions must happen first. According to the OpenEnv maintainers, agents succeeded about 90% of the time when tasks named explicit calendar IDs, but only about 40% when the same tasks used natural-language descriptions.

That's the kind of thing you want to discover in a sandbox, not in production!

Quick note about security. An environment doesn't make your agent secure in production. That's a different job, and it's where projects like agentgateway come in, with policies on what an agent can access

The connection with MCP

Some OpenEnv environments expose their tools through MCP, so any MCP-compatible agent can use them. The docs explain how this works.

OpenEnv is now part of AAIF

Since the meetup, AAIF announced four new projects: Agent Skills, Open Responses, OpenEnv and OpenSandbox. Hugging Face contributed OpenEnv, which it launched with Meta in 2025.

For me, this closes the loop of our first meetup. The PyTorch side brings training and serving, many of the AAIF projects bring the open standards agents use to work (MCP, Goose, AGENTS.md), and I'd say OpenEnv sits in the middle, where you test and train agents on the tasks you actually care about.

Testing it myself helped me understand all of this much better than reading about it. Next, I want to build a small environment from real tasks and see what it tells me about an agent like Goose. I'll share it here when I do!

Thanks to Ricardo, Carlos, Sergio, Red Hat and everyone who came! Watch the full recording (in Spanish) and follow PyTorch Meetups Madrid for future events.

Taking my GitHub Stats MCP Server to the Cloud 🚀☁️

Ana Jimenez Santamaria — Sun, 28 Jun 2026 17:45:44 +0000

👋 This is the third chapter of a series where I document what I'm learning about Model Context Protocol architecture and tool implementations

In Chapter 2, I built a GitHub Stats MCP server with CHAOSS security metrics. It worked, it returned real data, and Goose could orchestrate its tools into a security report. But it had one big limitation: it only ran on my laptop.

This time, I put it on the cloud for an external MCP client to reach it.

That means introducing a new MCP transport mechanism, containerizing the server with Docker, deploying it on Hugging Face Spaces, and setting up Goose extensions to point at a public URL instead of running a local command. Let's dive in!s

Laying out Foundational Concepts

Let's start with what the MCP spec documentation says about transports and then look at where Goose, the mcp host used in this example, fits in.

Streamable HTTP MCP Transport

In MCP, a transport is the layer that defines how a client and a server exchange their JSON-RPC messages. The standard currently defines two transport mechanisms, and the journey in this chapter is about moving from one model to the other:

stdio: The client launches the server as a subprocess and they communicate through standard input/output pipes.
Streamable HTTP: The MCP server runs as an independent HTTP service, typically exposed through a single endpoint. Clients send JSON-RPC messages using HTTP POST requests. The server can reply with a regular JSON response, or, when it needs to send multiple messages over time, it can return an SSE stream.

So while in Chapters 1 and 2, stdio was perfect for local development, for cloud deployment, I need a different model: one server running independently, reachable over the network, and updated in one place. That is what Streamable HTTP gives me.

Goose's Role as MPC host

In Chapter 2, Goose was the host. It holds the conversation, runs the model, and decides when to call my MCP tools.

What changes now is the transport. The tools, the resources, and the prompt my server exposes are identical to Chapter 2. Switching to Streamable HTTP doesn't touch any of them, it just changes how the client reaches the server: instead of Goose launching my server as a subprocess, Goose connects to a server that's already running at a URL. And because the door is now a public URL, any other MCP-compatible host that supports Streamable HTTP could connect to it too

An Always-on MCP Server

The server now has to stay up on its own, so it needs to live somewhere that isn't my laptop, which is why I containerize it and deploy it.

One bit of cloud plumbing is worth naming now because it shows up in the practical section: many cloud platforms put a reverse proxy in front of your container. Long-lived open streams like SSE can work, but they are often fragile unless the platform is configured for them (proxies may enforce idle timeouts or drop connections). For simpler deployments like this one, I run the server in a stateless mode where each interaction is handled as a plain HTTP request/response

With the standard in hand, the rest is implementation!

Step 1: Teaching the Server to Speak Streamable HTTP

The tempting move is to just switch the transport. Don't. Current Goose setup spawns the server over stdio, and flipping the transport would break it.

A cleaner pattern is one codebase that can run either transport, chosen at runtime. The tools, resources, and the prompt do not change. What changes is the way the host reaches the server: locally through stdio, or remotely through Streamable HTTP.

In practice, that means reading the transport from an environment variable and passing the right host and port when the server runs in HTTP mode.

import os
from mcp.server.fastmcp import FastMCP
mcp = FastMCP(
    "github-stats",
    host=os.getenv("MCP_HOST", "127.0.0.1"),
    port=int(os.getenv("MCP_PORT", "8000")),
    stateless_http=True,
    json_response=True,
)

# In this section, you add the  tools, the resources, and the prompt, which stays exactly the same as chapter 2 shows

if __name__ == "__main__":
    transport = os.getenv("MCP_TRANSPORT", "stdio")
    mcp.run(transport=transport)

stateless_http=True and json_response=True is the reverse-proxy problem from the theory section

Then, to test it locally:

MCP_TRANSPORT=streamable-http uv run server.py

The server is now live at http://127.0.0.1:8000/mcp. I opened the MCP Inspector, set the transport to Streamable HTTP, pointed it at that URL, and saw the exact same tools, resource, and prompt I had over stdio.

Step 2: Containerizing it

Hugging Face Spaces can host an arbitrary server as a Docker Space: you hand it a Dockerfile, it builds a container and runs it on a public HTTPS URL. So the next step was packaging the server.

Here's the shape of what the Space needs and what each piece is for:

github-stats-mcp/
├── server.py          # the MCP server (same as Chapter 2 + dual-transport add)
├── requirements.txt   # include mcp[cli], httpx, python-dotenv
├── Dockerfile         # set how HF builds and runs the container
├── README.md          # YAML header to tell HF this is a Docker Space
├── .dockerignore      # keeps junk and secrets out of the image
└── .env               # keep it local

The Dockerfile creates a non-root user (HF Spaces runs containers as a non-root user with uid 1000), and it bakes in the environment variables that flip the server into cloud mode:

MCP_TRANSPORT=streamable-http, MCP_HOST=0.0.0.0 (so it's reachable from outside the container), and MCP_PORT=7860 (the port HF routes public traffic to)

FROM python:3.11-slim

RUN useradd -m -u 1000 user
USER user
ENV PATH="/home/user/.local/bin:$PATH"

WORKDIR /app

COPY --chown=user requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY --chown=user . .

ENV MCP_TRANSPORT=streamable-http
ENV MCP_HOST=0.0.0.0
ENV MCP_PORT=7860

EXPOSE 7860

CMD ["python", "server.py"]

And .dockerignore keeps the noise (and, importantly, secrets, under .env) out of the image

Step 3: Deploying to Hugging Face

You can easily set the space SDK via Hugging Face

The README needs a YAML header so HF treats it as a Docker Space. The two lines that actually matter are sdk: docker and app_port: 7860 (which has to match MCP_PORT in the Dockerfile).

---
title: "GitHub Stats MCP"
emoji: 📊
colorFrom: yellow
colorTo: gray
sdk: docker
app_port: 7860
pinned: false
---

Then you create a new Docker Space, push server.py, Dockerfile, requirements.txt, README.md, and .dockerignore in your HF repo, and set the token as a secret in Settings. The server went live at a public .hf.space URL

Step 4: Reconnecting Goose to the Cloud

In Goose, I added the server as a remote extension pointing at the .hf.space/mcp URL instead of a local command. Same model switching, same chat, now talking to a server in the cloud. And not just Goose: any MCP client anywhere can now connect to that URL.

As last time, I used Qwen3-32b (via Groq) with my MCP tool activated and sent the prompt:

Goose passed it to the LLM along with my tool descriptions
The model decided it needed the tool
Goose executed that call against my server
The model formatted the result the way we wanted, grounded in the CHAOSS expert and context

I used the same project as in Chapter 2:

Then it dropped the report:

Authentication Note

At the end of Chapter 2, I said I would add a security layer with OpenID Connect in this cloud chapter. Once I actually deployed the server, I changed my mind. There are a few reasons.

The deployment itself deserved a full chapter: Adding auth on top would have buried the main story (moving the MCP server from stdio to a public cloud environment). That's why authentication will get its own treatment in a later chapter
Deploying it publicly made the auth problem more concrete: A public server changes the threat model immediately: anyone with the URL can call its tools, and every call consumes the GitHub token’s rate limit.
I am treating the deployment as a temporary sandbox, not a production setup: The server exposes no sensitive data, and the GitHub token is deliberately constrained: fine-grained, read-only, public-repositories-only, and with no account-level permissions.

But please note that this does not make authentication unnecessary. It only makes the remaining risk acceptable for this specific experiment (e.g., someone could burn through the token’s read rate limit for a while, but they could not access private data or perform write actions as me). For any persistent, shared, write-capable, or private-data-connected server, I would add authentication before exposing it publicly.

Final Remarks and Questions for the Next Chapter

This chapter shows the moment my server stopped being a local process someone runs and became a hosted service available at a URL. The server is deployed, and anyone can call it.

Deploying made the next question worth testing: What does MCP actually improve in the quality of the response, compared with asking the same model without MCP tools or with plain web search?

In the next chapter, I build a second server based on the other CHAOSS practitioner guide and metrics set: Responsiveness⁠, and its open knowledge. Then I run an experiment inspired by a community peer at CHAOSS, asking the same question to the same model in three different ways: with my MCP tools, without my MCP tools, and with plain web search.

Building a GitHub Stats MCP Server with Security Metrics

Ana Jimenez Santamaria — Sun, 31 May 2026 10:15:41 +0000

👋 This is the second chapter of a series where I document what I'm learning about Model Context Protocol Architecture and Tool implementations

In Chapter 1, I built a simple Calculator MCP Server. This time, I connected my MCP server to an external API, added the two other MCP structures (Resources and Prompts), and ended up with something useful for teams evaluating open source dependencies and ecosystem health: a security risk assessment tool powered byCHAOSS metrics, helping practitioners better interpret project health

Let's first get into the theory and new concepts

An Introduction to MCP Resources and Prompts

We briefly mentioned in the last post about the MCP's primitives:

Tools: Grants agency to the AI and are functions the LLM executes (e.g., get_repo_info())
Resources: Provides safe, contextual data the LLM can read a URL, a file, or an API response
Prompts: Structure the conversation with expert context templates (e.g., You are a data scientist analyzing CHAOSS metrics)

For this project, I needed all three: Tools to fetch GitHub data, Resources to load the CHAOSS guide, and Prompts to give the LLM the right expert context.

What is CHAOSS and why does it matter to build GitHUb Stats?

CHAOSS is a Linux Foundation project that develops metrics and frameworks for measuring the health of open source communities.

Their Practitioner Guides are particularly useful because they take complex community health topics, such as security, contributor sustainability, and responsiveness, and translate them into actionable metrics. These metrics can help anyone interpreting open source project data develop insights to improve the project’s health.

The one I focused on building my server is the CHAOSS Security Practitioner Guide, which centers on three primary metrics:

OpenSSF Best Practices Badge: whether the project follows OpenSSF security best practices.
Libyears: how outdated the project's dependencies are.

Libyears concept: if your project uses a dependency that's 2 years behind its latest release, that's 2 libyears of lag. Studies show that projects with high libyears are 4x more likely to have security vulnerabilities.

Release Frequency: how often security fixes and updates land in a release. A project that releases rarely may have fixes in the code that users can't access yet.

These three metrics together give a starting point for assessing the security posture of any open source project, which is something that an Open Source Manager in the OSPO could need when evaluating dependencies or reporting to security teams.

1. Setting up the project

Used the same stack as Chapter 1 (Python, uv, FastMCP) with two extra dependencies:

httpx: modern Python HTTP client for calling the GitHub API
python-dotenv: for managing the GitHub token securely via a .env file.

2. The MCP Tools

The key difference from Chapter 1 is that your MCP server now talks to an external API. I added five tools aligned wiht the CHAOSS practitioner guide to security:

from mcp.server.fastmcp import FastMCP
import httpx, os
from dotenv import load_dotenv

load_dotenv()
GITHUB_TOKEN = os.getenv("GITHUB_TOKEN")
HEADERS = {
    "Authorization": f"Bearer {GITHUB_TOKEN}",
    "Accept": "application/vnd.github+json"
}

mcp = FastMCP("github-stats")

@mcp.tool()
def get_repo_info(owner: str, repo: str) -> dict:
    """Get basic info and stats for a GitHub repository"""
    ...

@mcp.tool()
def get_release_frequency(owner: str, repo: str) -> dict:
    """Get release frequency info"""
    ...

@mcp.tool()
def get_security_advisories(owner: str, repo: str) -> dict:
    """Get known security advisories for a GitHub repository"""
    ...

@mcp.tool()
def get_dependency_info(owner: str, repo: str) -> dict:
    """Check what dependency files exist in a repo"""
    ...

@mcp.tool()
def get_libyears(owner: str, repo: str) -> dict:
    """Calculate CHAOSS Libyears metric"""
    ...

The last tool called Libyears was the most interesting to add. It uses GitHub's Dependency Graph SBOM API to get all dependencies, then queries PyPI for each package to find how far behind the current version is from the latest. A high libyears score means outdated dependencies, which, according to CHAOSS, correlates with higher security risk.

3. Adding Resources and Prompts

This is where MCP gets powerful beyond just tool calling.

Resource: the CHAOSS Security Guide

@mcp.resource("chaoss://security-guide")
def get_chaoss_security_guide() -> str:
    """CHAOSS Security Practitioner Guide content"""
    response = httpx.get("https://chaoss.community/practitioner-guide-security/")
    import re
    text = re.sub(r'<[^>]+>', ' ', response.text)
    text = re.sub(r'\s+', ' ', text).strip()
    return text[:8000]

This fetches the CHAOSS Security Practitioner Guide and makes it available to the LLM as a readable document. The host can load it into context when needed (so the model doesn't just have your tool results, it has the actual framework for interpreting them).

Prompt: the CHAOSS Security Analyst

@mcp.prompt()
def chaoss_security_analyst() -> str:
    """Expert prompt for CHAOSS security risk assessment from an OSPO perspective"""
    return """
You are a data scientist specializing in open source security metrics for OSPOs.

Your role is to analyze GitHub repositories using CHAOSS Security Practitioner Guide 
metrics and produce clear security risk assessments that OSPOs can present to their 
security teams.

When analyzing a repository, always:

1. INTERPRET metrics using these CHAOSS thresholds:
   Libyears: 0-2 = low risk, 2-5 = moderate risk, 5+ = high risk
   Release Frequency: weekly/monthly = healthy, quarterly or less = concern
   Security Advisories: 0 = good, any critical = immediate action needed

2. CONTEXTUALIZE results considering project size, team, and ecosystem.

3. STRUCTURE your output as a risk assessment report:
   Executive Summary, Metrics Summary, Risk Level, Recommendations, Why this matters
"""

The Prompt gives the LLM a specific expert role: you are a data scientist building a security report for an OSPO to present to their security team

4. Testing in the MCP Inspector

Same workflow as Chapter 1, run your server.py, open the Inspector, verify all 5 tools, 1 resource, and 1 prompt are visible and working.

5. Connect to Goose

I decided to test on a large, well-known open source ML framework.

I then connected the server to Goose exactly as in Chapter 1, then asked: Analyze [insert open source project name] security using all available GitHub-stats tools and give me a risk assessment with recommendations

After some model experimentation (Llama 3.3-70b had trouble with multiple tools, Qwen3-32b worked well), Goose called all 4 tools, synthesized the results with the CHAOSS context, and produced this:

Security Risk Assessment — [open source project]

Security Advisories: 5 total (including 1 critical — arbitrary code execution when loading malicious [open source project] checkpoint with weights_only=True, published January 2026)
Release Frequency: 30 releases, latest v2.12.0 — active and healthy
Open Issues: 18,496 — high volume, warrants triage
Risk Level: HIGH

Recommendations:

🚨 Patch unresolved security advisories immediately
⚠️ Review high number of open issues — 32% untriaged
✅ Release cadence is healthy — keep it up

A few considerations when reading this test report:

A "HIGH" risk level here does not mean this is a bad or insecure project. For a project of the scale I was analyzing (hundreds of thousands of users, a dedicated security team, etc), these numbers need to be interpreted in context.
The high open issue count reflects high community activity, not neglect. The disclosed security advisories are being actively managed and publicly reported, which is actually a sign of good security hygiene (projects that disclose vulnerabilities are more trustworthy than those that don't)
CHAOSS metrics are a starting point for conversation, not a final verdict. Security risk always depends on domain context (the same metric means something very different in a healthcare system versus a research prototype).

Final security decisions should always involve human judgment, domain expertise, and a deeper understanding of how the project is used in your specific context

Bonus point: Showing this in a web app

The transport method between Goose and our server is stdio. This means they communicate via stdin/stdout pipes. This is perfect for local development, but it means your server only exists while our machine is running and Goose is open.

Then, what if I want to share this as an open web dashboard and not just in a local chat interface?

Streamable HTTP is the MCP way of transport that lets an MCP server be exposed over HTTP, rather than only as a local process over stdio. In this scenario, client-to-server communicates using HTTP POST requests. When the server needs to send multiple messages over time, it responds with an SSE stream for server-to-client messages.

There are a few use cases that require that transport:

MCP Remote: server is deployed to the cloud, accessible via a public URL (e.g, This is already how the connectors in claude.ai work when you connect to Asana, Google Drive, etc)
MCP Apps: browser UIs that connect directly to your MCP server without needing a desktop AI host at all. A new experimental feature in the MCP Inspector.

If you're curious about where MCP official transport layers need to evolve for edge environments (like manufacturing, healthcare, or automotive) where latency and connectivity can't be taken for granted, this talk explores Binary MCP with Protocol Buffers for constrained networks

What's coming in Chapter 3

We will be exploring how to build a cloud-deployed version of our MCP server while adding a security layer using OpenID Connect.

The weekend I fell down the MCP rabbit hole

Ana Jimenez Santamaria — Mon, 18 May 2026 15:34:33 +0000

👋This is the start of a series where I document what I'm learning about Model Context Protocol Architecture and Tool implementations

I'd been reading about MCP for a while and felt like I had a good grasp of the concepts, but I hadn't actually shared any builds yet. So this series is me finally putting my hands on it, documenting what I'm learning (from Zero to Beginner), and sharing it in case it's useful to others going through the same thing

My learning is coming from a mix of things: Some books, a few YouTube tutorials, conversations with DevRel peers exploring similar things, and a fair amount of AI assistance to help me understand concepts along the way 😄 Let's start!

An Intro to Model Context Protocol (MCP)

In the MCP Standard book, by Srinivasan Sekar there is a perfect analogy to explain the problem MCP solves.

Picture this: you have "M" AI models and "N" tools you want to connect to them.

The Old Way: Without a standard, you'd have to build a unique integration for every single combination. That’s ‭$M \times N$‬‭‬ different connections and a total nightmare to maintain!
The MCP Way: MCP acts as the universal plug. You build your tool once to the MCP standard, and it instantly works with any model that speaks it.

If this scenario sounds familiar, it's what happened with containerization before Kubernetes. Kubernetes came along and said: Here's the standard. MCP is doing the same thing for AI tooling.

The 3 MCP Roles to Understand

Before building anything, there are three roles to wrap your head around:

The Host is the app the user interacts with directly. It decides which tools to call, keeps the conversation context, and manages clients. Think Claude Desktop, Goose, VS Code, Cursor.
The Client lives inside the host. It maintains the connection with a concrete MCP Server.
The Server answers client requests and exposes tools, resources, and prompts through the MCP protocol.

Before MCP, the AI agent was doing everything (fetching data, formatting it, calling the model, returning the answer. One giant piece of logic. Hard to test and hard to scale). After MCP, the agent only does one thing: reason.

Now that we’ve covered the high-level concepts of MCP, let's dive into the practical configuration!

Level 0: Let's build a Calculator

Not glamorous, but the perfect hello world for understanding the fundamentals

1. Using the MCP Python SDK

To build an MCP server, you don't need to implement the protocol from scratch. There is an official open source SDK (under MIT license) under the modelcontextprotocol organisation on GitHub.

Without the SDK you'd have to manually handle the JSON-RPC messages that flow between host and server via stdin/stdout, implement the handshake, route requests, serialize responses, etc. It's totally doable, but the SDK abstracts all of that.

2. Create the Server (server.py)

Inside the Python SDK, I decided to go with FastMCP, a specific class within the SDK that hides the complex protocol logic.

Here is the basic calculator, under a simple server.py:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("calculator")

@mcp.tool()
def multiply(a: float, b: float) -> float:
    """Multiply 2 numbers"""
    return a * b

# + add, subtract, divide...

if __name__ == "__main__":
    mcp.run()

💡In this scenario, server.py is the MCP Server, which exposes tools through the protocol.

3. Test Server and Tools

Before connecting to any AI host, I tested my server with the official MCP Inspector. Note I'm using uv to manage the environment and run the development tools when running the inspector:

uv run mcp dev server.py

A browser UI opens. You'll see: status "Connected", server name "calculator", SDK version, and the history.

💡 The MCP Inspector is acting as both Host and Client here: doing the handshake, maintaining the connection, calling your tools

4. Connect to a Host

I tested three options:

🪿 Goose

Goose is an open-source AI agent that can act as an MCP Client and has a visual form to configure the extension name, type (STDIO), and the command it runs every time it starts. Internally, it stores config in a YAML file you never touch.

✳️ Claude Desktop

Claude Desktop needs you to configure a manual JSON such as:

{
  "mcpServers": {
    "calculator": {
      "command": "/path/to/uv",
      "args": ["run", "--directory", "/path/to/project", "python3", "server.py"]
    }
  }
}

🤖 VS Code + Copilot

Same JSON approach as Claude Desktop inside settings.json.

Here is a quick comparison of the three environments I’ve been testing, including a breakdown of their models, costs, and setup methods:

	Goose	Claude Desktop	VS Code + Copilot
Model	Llama 3.3-70b	Claude Opus 4.6	GPT-4o
Provider	Groq	Anthropic	GitHub Copilot
MCP Config	Visual UI - YAML config	Manual JSON config	Manual JSON config
API Cost	14,400 req/day	Pay per use	Free tier (50 chats/month)
Local model option	Yes (Ollama)	No	No

💡 Each host manages its own MCP Client internally. You don't write client code (the host handles that). Your job as a "server developer" is just to make sure your server speaks valid MCP.

5. Full MCP Cycle Overview

As a takeaway, let's summarize the process into this 8-step cycle:

1 User type the query and the Host receives it
2 Host passes it to the LLM for initial reasoning. LLM decides: "I need an external tool for this"
3 LLM signals tool invocation intent to the Host
4 Host delegates to the Client (the messenger)
5 Client serializes the request in JSON-RPC and sends it to your MCP Server via stdin/stdout
6 Server validates and executes your Python function
7 Server returns a standard MCP response
8 Host shows the result to the user

What's Next?

The calculator was self-contained (all logic lived in server.py). In my next post, I'll share my experience in building a GitHub Stats server to talk to an external API and how to handle authentication, rate limits, and what data to expose to the LLM.

Resources

Dockerizing your first web app with python and flask

Ana Jimenez Santamaria — Sun, 19 Jul 2020 21:02:28 +0000

Second part of how to measure covid-19 impact on Jitsi project with python and elasticsearch. This time, my colleagues (David, Gerardo) and I (Ana) built a web app with Python technology and Flask framework and dockerized it. Here we explain you how

Docker architecture

First, we have to build a docker application with three containers:

ElasticSearch image
Kibana image
Web app image

For ElasticSearch and Kibana, we use pre-built images from DockerHub using 7.8.0 version. Web application uses a redis-alpine image.

Note: The reason why using alpine, is because this alternative is smaller and more resource efficient than traditional GNU/Linux distributions (such as Ubuntu)

Required files and configuration

You can get the required materials on GitLab. The image below shows the different files you will get by cloning the repo

Docker-compose.yml structure

docker-compose.yml file shows the structure explained in previous section


version: '3'
services:
  web:
    build: .
  ports:
    - 5000:5000
  networks:
    - elastic
redis:
   image: "redis:alpine"
es01:
   image: docker.elastic.co/elasticsearch/elasticsearch:7.8.0
   container_name: es01
   environment:
      - node.name=es01
      - cluster.name=es-docker-cluster
      - discovery.type=single-node
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms1024m -Xmx1024m"
  ulimits:
    memlock:
        soft: -1
        hard: -1
    volumes:
      - data01:/usr/share/elasticsearch/data
    ports:
      - 9200:9200
    networks:
      - elastic
  kib01:
    image: docker.elastic.co/kibana/kibana:7.8.0
    container_name: kib01
    ports:
      - 5601:5601
    environment:
      ELASTICSEARCH_URL: http://es01:9200
      ELASTICSEARCH_HOSTS: http://es01:9200
    networks:
      - elastic
volumes:
  data01:
    driver: local
  data02:
    driver: local
  data03:
    driver: local
networks:
  elastic:
    driver: bridge

Let's take a look at the main tags stated at docker-compose.yml

Ports: configures docker port with host machine port where docker runs. In this case, 5000, 5601 and 9200.
Image: docker image that is downloaded for the required service
Networks: this is named as 'elastic' in order to connect the three services
Environment: configures environment variables essential to operate among services, such as RAM memory parameters. Within Kibana service, it is necessary to define the variables ELASTICSEARCH_URL and ELASTICSEARCH_HOSTS, in order to link it with the Elasticsearch service.

Dockerfile configuration

Dockerfile has the required steps to configure the web application to link with our python script that extract and store the data in an Elasticsearch cluster, that at the same time imports impact_dashboard.ndjson on Kibana for previous visualization.

It runs on alpine distribution to copy the required folders to get the app running. Moreover, and thanks to requirements.txt, you can add all the dependencies that the python script needs.

FROM python:3.7-alpine
WORKDIR /code
ENV FLASK_APP jitsi-data.py
ENV FLASK_RUN_HOST 0.0.0.0
RUN apk add --no-cache git
RUN apk add --no-cache tk-dev
RUN apk add --no-cache gcc musl-dev linux-headers
COPY requirements.txt requirements.txt
COPY mapping.json mapping.json
COPY templates templates
COPY impact_dashboard.ndjson impact_dashboard.ndjson
RUN pip install -r requirements.txt
EXPOSE 5000
COPY . .
CMD ["flask", "run"]

How to start containters

In order to start the application (with docker and docker-compose previously installed) open your terminal and execute the following command

$ docker-compose up

This will initiate the different commands stated in dockerfile and download the required docker images. Once that's finished, you can check that Elasticsearch (localhost:9200) and Kibana (localhost:5601) are succesfully running.

Now, it's time to go where python Flask application web app is located, using port 5000

Clicking on start button will initialize data extraction from Jitsi git data (check jitsi-data.py for more details) and will store such data to our ElasticSearch. Finally, it will import impact_dashboard.ndjson to our Kibana, allowing us to interactively play with the data.

Once the process is finished, the browser will show the next message:

Of course, we can see if our Elasticsearch index and Kibana dashboard have successfully being added to our instances:

By default the time filter is set to the last 15 minutes. You can use the Time Picker to change the time filter or select a specific time interval or time range in the histogram at the top of the page.

et voilà now you have a cool dashboard up and running to analyze how a pandemic can impact Jitsi software development activity.

Bonus point: uploading a Docker image to Docker Hub

With a Docker Hub account, you can build an image where dockerfile is located. Simply type:

$ docker build -t dockerhubID/DockerHubreponame:imagetag .

Then, upload the image to your Docker Hub repo (you can create the repo using the Docker Hub UI

$ sudo docker push dockerhubID/DockerHubreponame:imagetag

Once the image is uploaded to Docker Hub, any user can use and run the app with the following docker-compose.yml

version: '3'
services:
  web:
    image: daviddp92/jitsi-data-extraction:1.0.0
    ports:
      - 5000:5000
    networks:
      - elastic
  es01:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.8.0
    container_name: es01
    environment:
      - node.name=es01
      - cluster.name=es-docker-cluster
      - discovery.type=single-node
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms1024m -Xmx1024m"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - data01:/usr/share/elasticsearch/data
    ports:
      - 9200:9200
    networks:
      - elastic
  kib01:
    image: docker.elastic.co/kibana/kibana:7.8.0
    container_name: kib01
    ports:
      - 5601:5601
    environment:
      ELASTICSEARCH_URL: http://es01:9200
      ELASTICSEARCH_HOSTS: http://es01:9200
    networks:
      - elastic
volumes:
  data01:
    driver: local
  data02:
    driver: local
  data03:
    driver: local
networks:
  elastic:
    driver: bridge

Closing thoughts

We have learned how to dockerize a web app with Python technology and Flask framework using docker-compose. We also saw how to use and run the application using Docker Hub images.

What do you think about this project? What should we improve? Feedback is more than welcome :)

How to measure Covid-19 impact on Jitsi project with Python and ElasticSearch

Ana Jimenez Santamaria — Fri, 03 Jul 2020 13:13:32 +0000

The situation with Covid-19 limits the possibility of face-to-face communication. Remote work is now a reality, and the demand for video conferencing such as Jitsi Meet continues breaking records.

Could it be possible that Jitsi’s software development activity and community are on high-demand too?

// Detect dark theme var iframe = document.getElementById('tweet-1235916871783919617-496'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1235916871783919617&theme=dark" }

This post summarizes one of the analysis that my colleagues David Duran, Gerardo Aguirre and I did for our M.S. in Data Science. Following the GQM approach, we defined a clear goal and some related questions. Then, we decided the best metrics to answer those questions.

Goal

Analyze the impact that a global pandemic such as Covid-19 has on Jitsi

Questions

Did Covid-19 countermeasures change:

Jitsi’s activity patterns?
Jitsi’s diversity patterns?
Jitsi’s community risk?

As we are trying to measure impact, we need to see potential changes. For instance, did software development activity change during covid-19 outbreak compared to last year?

We selected Feb 1st- May 31st 2019 and 2020 as our timeframe to measure such impact.

Metrics

Contributor Activity	Contributor Diversity	Community Risk
Total Contributors	Organization Diversity	Bus Factor
Total Commits	Gender diversity
	Timezone Diversity

Total Contributors: number of authors that made a commit over a period of time
Total Commits: number of commits over a period of time

Organization Diversity: different email domains over a period of time. Here we can find company’s domains (e.g jitsi, 8x8, etc) or individual’s (gmail, users, etc)

Gender Diversity: total share of female and male author names that made a commit

Timezone diversity: existing authors on each timezone

Bus Factor: minimum number of contributors needed to make the 50% of git code on Jitsi over a period of time

Tools used

Data gathering and storage

For data gathering we used an open source tool called Perceval. Perceval offers a Python module for retrieving data from repositories related to software development. It works with many data sources, from Git repositories and GitHub projects to mailing lists, Gerrit or StackOverflow.

For this specific analysis, we will just need Jitsi Git data.

If you are running Jitsi-data.py available in this Gitlab repo, make sure you have installed perceval first

$ pip install perceval

You can simply use perceval git module on python with perceval.backends.core.git:

import json
from elasticsearch import Elasticsearch
import logging
from datetime import datetime  # to specify a specific timeframe
import gender_guesser.detector as gender
from perceval.backends.core.git import Git
from dateutil.parser import parse

Perceval has 2 arguments for Git:

URI: the repository or list of repos from GitLab or GitHub you want to analyze
Gitpath: usually something like /tmp/repo-name.git

# It has 2 arguments, uri and gitpath: repo = Git(uri=repository, gitpath='/tmp/'+repository.git)
data_repo = Git(uri='https://github.com/jitsi/jitsi-meet', gitpath='/tmp/jitsi-meet.git')

Moreover, we use Python Elasticsearch client to store data and mapping from python script to our ElasticSearch instance.

# Instance of elasticsearch to put the data into ElasticSearch/Kibana system (it is necessary to have both up on localhost)
    elastic = Elasticsearch()
    # Read mapping json file to ElasticSearch
    mapping_file = open("mapping.json", "r")
    mapping = json.load(mapping_file)
    # Creation of ElasticSearch index using the mapping
    index_name = "repo_jitsi_index_def"
    response = elastic.indices.create(
        index=index_name,
        body=mapping,
        ignore=400  # ignore 400 already exists code
    )

Data transformation and mapping

Perceval gives us raw git data with a lot of information over a period of time (we specify this thanks to datetime python package): Commit, Author, Lines added, Lines removed, Email, Commit Date and more.

However, in order to analyze contributor diversity, we need to create new fields with the data provided. That's why we add organization (based on email domains), gender (using a gender detector python package) and timezone fields (cleaning item field)

You can see how we iterate through the different fields provided by Perceval to get the data in our GitLab repo

Once we generate these new fields, we create our Elasticsearch mapping, transforming item data into a new structure matching the mapping for ElasticSearch

Data visualization

If you are running unity-data.py script with your Elasticsearch and Kibana instance opened, you can go to your Kibana localhost (usually 5601) > management > index patterns and click on create index pattern. You should see the index name given at jitsi-data.py (by default is repo_jitsi_index_def)

We then elaborate a Kibana dashboard with the specific visualizations that fits best with our defined metrics. We called it “impact_dashoard”

At a first glance, we can see an uncommon behavior on Jitsi’s activity since February 2020:

And when comparing 2019 period with 2020, results are also quite interesting:

Image below highlights major changes regarding contributor’s diversity and activity:

We can see that:

Contributor’s Activity increased: there is an increase in commit activity, lines added and removed, authors and organizations involved on Jitsi’s software development

Contributor's Diversity increased: It’s interesting to see that women activity was under 1% last year and since covid-19 started, it increased to 8%. Still a low number, but is a good indicator.

Also, we see some author activity in Asia that didn’t existed before.

Disclaimer: there are “unknown” data that our gender detector couldn’t guess. The main reason is because some Jitsi’s developers have non-occidental characters and our gender detector is optimized for occidental names. We did an exhaustive cleaning for the most relevant names though, reducing our “unknown” data, but we couldn’t erase it completely.

What about Community Risk?

To answer our last question and metric, we work on a query using Jupyter Notebook.

The Bus Factor for developers isn’t something new: It is the minimum number of team members that have to suddenly disappear from a project before the project stalls due to lack of knowledgeable or competent personnel. In other words:

Our Bus Factor approach for our specific goal answers the question Which is the minimum number of contributors needed to make the 50% of git code on Jitsi?

As a result, we get that in 2019, Jitsi only needed 2 developers to make the 50% of git code while in 2020 Jitsi needs at least 9 developers. This fact is indeed good for Jitsi’s project health!

You can see Jupyter Notebook query in our GitLab repo

Future Work

This is just a very introductory analysis to measure covid-19 impact on Jitsi. Of course, we can improve a lot of things. Some future work might be:

Improve author affiliation: We know an existing open source tooling called SortingHat, that can be implemented with Perceval and other GrimoireLab components. SortingHat is an identity affiliation management. Thus, identities corresponding to the same real person can be merged in the same unique identity with a unique uuid.
Filter “unknown” category within gender term: Maybe gender-guesser package is not the best one to use. Do you know other python packages we can use? Leave your comments below :)
Work on new metric for risk assessment, such as the Gini coefficient.

And last but not least: Correlation does not imply causation. We don’t have all the domain knowledge Jitsi maintainers and community specialists might have. A relationship between Covid-19 and contributor's activity might be just coincidence

Remote work: The Open Source Way

Ana Jimenez Santamaria — Fri, 13 Mar 2020 22:40:59 +0000

Working remotely has become mission-critical now more than ever. Since one of the recommendations to stop COVID-19 massive spread is to stay at home, many companies are seeking effective strategies and tools for remote work.

For many people, this situation could be an overwhelming first-time experience, but for many others this is not something new: People behind Open Source programs have been involved in remote collaborative workspaces since decades. How does the Open Source ecosystem manage remote workforce?

Everything starts with culture

People is desperately asking for collaborative tools to stay productive and connected. But is that the best approach?

Think about it, Why giving to someone that has never handle remote work, a bunch of tools without context? In fact, tooling is the last thing you should be thinking of. Open Source has succeed over the past years not just because of tools, but because of culture

Before going nuts with what tools should people use, I suggest to first investigate what strategies are used within open source communities and what can companies learn from them.

This way of thinking can somehow relate to InnerSource term: a methodology which main goal is to establish open source-like culture within organizations. It has a consolidated and active community, called InnerSource Commons

Hands on remote-work: Best practices and suggestions

In my company -Committed Open Source practitioners- working from home has never been a problem- We have been doing it since always!- This might be the reason why, some people from Twitterverse and Instagram asked me about best practices to follow in order to manage remote collaboration and productivity. Then I though that the best way to answer was by sharing my top 6 best practices

Document everything: As in person-meetings are not an option, internal documentation plays an important role to ensure collaboration. This is a really common practice within open source projects, as code is being build collaboratively and remotely, done by people from different time zones and cultures. Some of them are experienced contributors, others are just newbies trying to get into their first open source contribution. in both cases, they need to know how to contribute - as well as pitfalls to avoid, guidelines, etc- and such information needs to be accessible and visible for everyone.
Build a Kanban board: One of the main resources coming from Agile methodologies that can be applied for any situations that requires organizing and scheduling tasks. This is so helpfull that I'm not only use it at work to coordinate tasks with my team, but also with my classmates for my Data Science MS... Even for my personal projects!

Schedule daily meetings to keep track of current work: This will help to keep your team synchronized, know what they are working at and find potential bottle necks... A good idea is to focus on short tasks, that can be done within 1 or 3 days period to track better the activity
Set your own working hours and breaks: set up an alarm and create a daily routine for work. The same way you do at work,dress up -avoid full-day pijama- and have specific clock-in and clock-out hours. This is very helpful to divide work vs spare time, and not fall into an endless working state that at some point will lead into a burnout.

Socialize: working from home doesn't mean you can't have great coffee break conversations with your teammates!. At my company, Every Friday at 2:00pm, we have what we call coffee-chats -. We join the call, talk about our week, and enjoy a nice cup of coffee with friends!

Do Exercise + healthy diet: I'm quite a restless person*, which means I need to remain focus and productive as much as possible if I want to do all the activities I've planned for that day.

*I have full-time work, Data Science MS, Japanese, and boxing classes, while saving time for my family and friends... All in the same week!

Boxing classes helped me a lot when covid-19 situation was not there, but now that gym is not the best place to be, I still doing some cardio at home to relieve stress. Moreover, avoiding added sugar and fast food intake made me feel less tired and more proactive during the day

Tooling

Once you have define a way of collaborative work and clear daily routines, it's time to look at the resources you need to make that possible.

There are lots of things you need to keep an eye on when choosing the best tool for you: Data Privacy, licenses, budget, scalability and more. However, taking into account that I'm not an expert on this field, I'll just enumerate some of my favorite tools I have been using during the past year at work or personal projects, grouped by different scenarios:

Communication Apps

Slack: similar to telegram, but more specialized for remote teams. you can have different channels which makes great to communicate among different working teams, topics or departments

Video chat

Jitsi.meet: No log ins and completely free video conferencing. You know what's best? it's fully encrypted!

Time management

Trello: really useful for those willing to use a Kanban board to manage daily tasks

File hosting services

NextCloud: Actually this is the only one I haven't use it yet, but I've heard a lot of positive feedback about this tool! Despite other alternatives, this solution does NOT store your data.

Podcast/interview recording

Etercast If you're planing to have several guests for an interview, Etercast might be a good solution. No log in, free and very easy to manage

Note: This post by Jesús González-Barahona shows more resources, also applied for distance learning. The best thing is that all of them are entirely free, open source software (FOSS)

Closing thoughts

Not every business is suitable for remote work: My goal here is not to show that everyone can work remotely -cause we can't-, but to give some guidance to those few who potentially can but don't know how to start with and share my thoughts and experience working in remote and collaborative environments.

Thanks for reading until the end. For those experienced people in collaborative and remote environments, I'd love to see any suggestions or tools that you might find useful to share to folks who are facing remote work for their first time.

Feedback is more than welcome :)