Open {re}Source | Articles

Running a Local AI Inside Obsidian with Ollama

Sun, 01 Feb 2026 00:00:00 GMT

What if your notes could think with you, without sending a single word to the cloud? In this article, we’ll build a fully local AI setup inside Obsidian using Ollama and the open Gemma 3 model. You’ll learn why local AI makes sense for knowledge work, how to install and test Ollama from the command line, how to connect it to Obsidian using community plugins, and how to use it for practical, everyday note-taking workflows, all while keeping full control over your data.

Why Local AI in a Notes App?

Before jumping into installation, it’s worth clarifying what is and isn’t open source in this setup, and why it still aligns strongly with open source values.

Obsidian is an application that allows users to create and manage notes using plain text Markdown files stored locally on their devices.

Obsidian is not open source itself, but supports open source community plugins, and is local-first:

Notes are plain Markdown files
Stored on your own filesystem
No mandatory account or cloud dependency
Easy to migrate, back up, or process with other tools

This dramatically reduces vendor lock-in. Even without Obsidian, your knowledge remains usable.

Ollama is an open source tool that lets you run AI models locally on your machine:

Runs open models locally
Exposes a local HTTP API
Requires no internet once models are installed
Never sends your data elsewhere

Together, Obsidian and Ollama create a powerful combination that aligns with open source values: local notes, local AI for privacy, and knowledge work that you actually control.

What We’ll Build

By the end of this article, you’ll have:

Ollama installed and verified from the command line
The Gemma 3 model running locally
Obsidian configured with community plugins
A fully local AI assistant embedded in your notes

Everything described below has been tested using Gemma 3 with Ollama.

Let’s consider that Obsidian is already installed on your machine. If you haven’t done so yet, you can download it from obsidian.md.

Step 1: Install and Test Ollama (Command Line First)

Install Ollama from the official site at https://ollama.com, or via Homebrew on macOS via
```
brew install ollama
```
Verify the installation by running in your terminal:
```
ollama --version
```
The output should show the installed version of Ollama.
Pull and run the Gemma 3 model with:
```
ollama run gemma3
```
Once the model is downloaded, you’ll get an interactive prompt. Test it with:
```
Explain what a local-first application is in one paragraph.
```
If you receive a response, everything is working correctly.
Exit the chat with the command:
```
/bye
```
Ollama also starts a local API server at http://localhost:11434.

Opening this URL in your browser will show the “Ollama API is running” message. This endpoint is what Obsidian will use next.

Step 2: Install the Required Obsidian Community Plugins

To connect Obsidian to Ollama, you’ll need two open source Obsidian community plugins created by Pavel Frankov:

AI Providers
Local GPT

pfrankov/
obsidian-local-gpt Local Ollama and OpenAI-like GPT's assistance for maximum privacy and offline access

pfrankov/
obsidian-ai-providers This plugin is a hub for setting AI providers (OpenAI-like, Ollama and more) in one place.

AI Providers

Let’s start by installing the AI Providers plugin.

In Obsidian, go to “Settings → Community Plugins → Browse” and search for “AI Providers”.
Click “Install”, then “Enable” to enable the plugin.
Click “Options” to configure the plugin:
- In the “AI providers” section, click ”+” to add a new provider.
- In the “Add new provider” dialog:
  - Select “Ollama” as the provider type.
  - Click on the refresh icon of the “Model” field to fetch Gemma 3 from your local Ollama installation.
  - Click “Save” to add the provider.

Local GPT

Then, install the Local GPT plugin.

In Obsidian, go to “Settings → Community Plugins → Browse” and search for “Local GPT”.
Click “Install”, then “Enable” to enable the plugin.
Click “Options” to configure the plugin:
- In the “Main AI Provider”, “Embedding AI Provider”, and “Vision AI Provider” sections, select “Ollama ~ gemma3:latest” from the dropdown.

Step 3: Attach Hot Keys for Quick Access

To quickly access Local GPT features, set up hot keys in Obsidian.

In Obsidian, go to “Settings → Hotkeys”.
Filter by “Local”.
Assign hot keys to the following commands:
- For “Local GPT: Action Palette”, click on ”+” and press your desired key combination (e.g., ⌘ + J).
- For “Local GPT: Show context menu”, click on ”+” and press your desired key combination (e.g., ⌘ + M).

Step 4: Test Local GPT Inside Obsidian

Now that everything is set up, it’s time to test Local GPT inside Obsidian.

Two hot keys are set up: one for the action palette and one for the context menu.

The context menu is a quick way to apply AI actions to selected text.

Open any note in Obsidian.
Select some text you want to process with AI.
Press the hot key you assigned for “Local GPT: Show context menu” (e.g., ⌘ + M). It will open a context menu with various AI actions you can perform on the selected text:
- General help
- Continue writing
- Summarize
- Fix spelling and grammar
- Find action items
- New System Prompt
Please note that you can create your own custom prompts as well.

Let’s say I’ve written this article in Obsidian first and wanted to summarize it. I would select the text and use the context menu to choose “Summarize”.

Gemma 3 would then generate a concise summary of the selected content directly at the end of my note (this can be configured).

Using the Action Palette

The action palette allows you to type custom prompts and interact with Local GPT more freely.

Open any note in Obsidian.
Press the hot key you assigned for “Local GPT: Action Palette” (e.g., ⌘ + J). It will open the action palette where you can type your prompt.

Let’s say I want to analyze an image to describe its content. I would select the image in my note, open the action palette, and type: “Describe this image!”

The model would then generate a description of the image directly in my note.

Everyday Use Cases That Actually Feel Useful

I just scratched the surface of what you can do with this setup, and honestly, it’s pretty useful for specific tasks. Gemma 3 works well for close-to-the-text stuff: cleaning up messy first drafts, turning rambling meeting notes into actual bullet points, or getting a quick summary when I don’t want to reread a long note.

Response times are decent for most tasks. Not instant, but fast enough to keep you in the flow.

Where I use it most is rewriting awkward sentences, expanding bullet points when I need more detail, or brainstorming different ways to phrase something. It’s also surprisingly good at catching unclear writing that I might miss.

But it definitely has limits. It can’t access other notes in my vault (just the current one), struggles with complex reasoning, and sometimes gives generic responses if your prompt is too vague. I’m also not sure how well it handles really technical content as I’ve had mixed results there.

The key thing I’ve learned is that it works best as an editing partner for stuff you’ve already written, rather than generating ideas from scratch.

Maybe a more powerful setup could mix local and cloud models, using local for sensitive stuff and cloud for heavy lifting when needed. But for now, this local-first approach feels like a solid step toward more private, controllable AI in my writing workflow.

Trade-Offs (And Why They’re Worth It)

Local AI isn’t perfect:

Slower than cloud-hosted models
Smaller context windows
Less immediate “wow” factor than other cloud paid systems

But in exchange, you get:

Privacy by default
Zero marginal cost
Full control over models and prompts
No vendor dependency or platform lock-in

For personal knowledge management and everyday writing, that trade-off is often not just acceptable, but desirable.

Local AI inside Obsidian isn’t about chasing the biggest model: it’s about reclaiming agency over how you think and write. By combining a local-first notes app with open models running through Ollama, you get an AI workflow that is private, hackable, and built to last. In a world increasingly defined by opaque clouds and locked platforms, this setup quietly proves that powerful tools don’t have to come at the cost of control.

If you try out this setup, let me know how it goes! Share your experiences, tips, or custom workflows in our social platforms.

Happy note-taking!

Coding LinkedIn Carousels

Sun, 29 Sep 2024 00:00:00 GMT

Coding LinkedIn carousels… yes, not using design tools but using developer tools! It’s now possible!

A few days ago, we shared a new article on LinkedIn and tried to make it more engaging by using a carousel. And creating a carousel on LinkedIn can take a bit of time, especially if you’re not that familiar with design tools such as Canva, Figma, or even Penpot, our open-source design tool friend. Even with the tons of templates available out there, customizing them is a lot of work.

In the open-source software world, we are mostly developers, we’re not going to lie. So, we thought: “Why not code the LinkedIn carousel?” And that’s what we did!

How LinkedIn carousels work

Just for those who are not familiar with LinkedIn carousels, they are a series of images or slides that you can swipe through. They are a great way to share information in a visually appealing format. You can use them to showcase your open-source project, share tips, or even tell a story.

There’s no really a creator tool for LinkedIn carousels, so you have to create them yourself.

Basically, a LinkedIn carousel is in fact a PDF file. You can create a PDF file with multiple pages, and each page will be a slide in your carousel. You can then upload this PDF file to LinkedIn, and it will automatically convert it into a carousel.

On LinkedIn, click on the ”+ Create” button.
Select “Start a post”.
Click on the ”+” icon, and “Add a document”.
Select your PDF file, choose a document title, and LinkedIn will convert it into a carousel.

The Idea

So, if it just a PDF file, why not code it? We can create a simple HTML file with multiple slides, and then convert it into a PDF file. And that’s what we did!

We already use this great tool for presentations, it’s called Slidev.

Slidev is a presentation tool based on Vue.js. It allows you to create beautiful slides with Markdown and code. And it has a feature to export your slides as a PDF file. It is an open-source project, under the MIT license.

slidevjs/
slidev Presentation Slides for Developers

How to Code LinkedIn Carousels

It’s really simple in fact.

The first step is to create a new Slidev project. You can do this by running the following command:

npm init slidev@latest

This will create a new Slidev project in the current directory. You can then open the project in your code editor and start customizing the slides.

Obviously, you’ll notice that the default Slidev theme is not really suitable for LinkedIn carousels as the slides are generally in landscape format, in 16:9 ratio. So, you’ll need to customize the theme to make it more suitable for LinkedIn carousels.

In the slides.md you just have to add the following properties in the frontmatter:

---
aspectRatio: "3/4"
canvasWidth: 800

Just install playwright-chromium as a dev dependency, and export your slides as a PDF file:

npm install -D playwright-chromium
npm run export

And voilà, you got a nice slides-export.pdf that could be used as a LinkedIn carousel!

We Created a Theme for LinkedIn Carousels

However, you’ll notice that you still have some design work to do in order to render your carousel more visually appealing.

So, we created a theme for LinkedIn carousels called slidev-theme-linkedin-carousel, that is an open-source project under the MIT license.

Open-reSource/
slidev-theme-linkedin-carousel Slidev theme to create LinkedIn carousels

Here’s how it looks like: https://slidev-theme-lk-carousel.netlify.app.

How to Use the Theme

To use the theme, you just have to install it as a dev dependency:

npm i -D slidev-theme-linkedin-carousel

and then add the following frontmatter to your slides:

---
theme: linkedin-carousel
---

For more information on how to use the theme, check out the README.

The example.md file in the repository is a good starting point to create your own LinkedIn carousels. And from there, you can customize the slides to your liking, and even use custom components to make them more impacting.

That’s how you can code LinkedIn carousels. It’s a great way to share information in a visually appealing format, and it’s also a fun way to learn new things. We hope you enjoyed this guide, and we can’t wait to see what you create!

Don’t hesitate to share your LinkedIn carousels with us, we’d love to see them! See ya on LinkedIn!

If you liked this theme, use it, please consider giving it a star on GitHub, or even sponsoring us. It helps us a lot!

Add Funding Links to Your 'package.json'

Sun, 22 Sep 2024 00:00:00 GMT

Fund your open-source project by adding funding links to your package.json file. Who knows, you might get a coffee or two out of it!

Funding Open-Source Projects?

If you’re not new to the content of Open {re}Source, you know a thing or two about the importance of financing and funding open-source projects. The time and effort that maintainers put into their projects are invaluable, and it’s essential to support them in any way possible.

Supporting open-source projects can be as simple as starring a repository, contributing to the codebase, or even providing financial support. The latter can be done through platforms like GitHub Sponsors, Open Collective, or even through direct donations.

Packages Are Looking for Funding

Have you ever noticed the funding information displayed when you run the npm i command in your terminal?

% npm install

247 packages are looking for funding
  run `npm fund` for details

You Can Turn It Off, by the Way

If you’re not a fan of the funding information displayed when installing packages, you can turn it off by setting the --no-fund flag when running the npm install command.

You can also set it as a default behavior by running npm config set fund false.

Or you can turn it off in your .npmrc file in your home directory (~/.npmrc) manually or in your project’s .npmrc file:

fund = false

`npm fund` Command

Have you already launched npm fund in your terminal? If not, go ahead and do it now in one of your projects.

Here’s what it looks like for this repository:

[email protected]
├── https://opencollective.com/fakerjs
│   └── @faker-js/[email protected]
├── https://dotenvx.com
│   └── [email protected]
├── https://github.com/sponsors/wooorm
│   └── [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
├── https://opencollective.com/vitest
│   └── [email protected], @vitest/[email protected], @vitest/[email protected], @vitest/[email protected], @vitest/[email protected], @vitest/[email protected], @vitest/[email protected], @vitest/[email protected], [email protected]
├─┬ https://paulmillr.com/funding/
│ │ └── [email protected]
│ ├── https://github.com/sponsors/jonschlinkert
│ │   └── [email protected], [email protected]
│ └── https://github.com/sponsors/sindresorhus
│     └── [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
├── https://github.com/prettier/prettier?sponsor=1
│   └── [email protected]
├── https://github.com/sponsors/epoberezkin
│   └── [email protected]
├── https://github.com/sponsors/feross
│   └── [email protected], [email protected], [email protected]
├─┬ https://github.com/chalk/wrap-ansi?sponsor=1
│ │ └── [email protected], [email protected]
│ └── https://github.com/chalk/ansi-styles?sponsor=1
│     └── [email protected], [email protected]
├── https://opencollective.com/unified
│   └── [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], @mdx-js/[email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
├── https://locize.com
│   └── [email protected]
├── https://github.com/sponsors/antfu
│   └── [email protected]
├── https://github.com/sponsors/colinhacks
│   └── [email protected]
├─┬ https://opencollective.com/postcss/
│ │ └── [email protected], [email protected]
│ └── https://github.com/sponsors/ai
│     └── [email protected]
├── https://github.com/sponsors/isaacs
│   └── [email protected], [email protected], [email protected], [email protected]
├─┬ https://opencollective.com/babel
│ │ └── @babel/[email protected]
│ └── https://opencollective.com/browserslist
│     └── [email protected], [email protected], [email protected]
├── https://github.com/sponsors/sibiraj-s
│   └── [email protected]
├─┬ https://github.com/chalk/strip-ansi?sponsor=1
│ │ └── [email protected]
│ └── https://github.com/chalk/ansi-regex?sponsor=1
│     └── [email protected]
├── https://github.com/vitejs/vite?sponsor=1
│   └── [email protected]
├── https://opencollective.com/libvips
│   └── [email protected], @img/[email protected], @img/[email protected]
├─┬ https://github.com/sponsors/fb55
│ │ └── [email protected], [email protected], [email protected]
│ ├── https://github.com/fb55/domhandler?sponsor=1
│ │   └── [email protected]
│ └─┬ https://github.com/fb55/domutils?sponsor=1
│   │ └── [email protected]
│   └── https://github.com/cheeriojs/dom-serializer?sponsor=1
│       └── [email protected]
├── https://github.com/fb55/htmlparser2?sponsor=1
│   └── [email protected]
├── https://github.com/sponsors/NaturalIntelligence
│   └── [email protected]
├─┬ https://github.com/privatenumber/get-tsconfig?sponsor=1
│ │ └── [email protected]
│ └── https://github.com/privatenumber/resolve-pkg-maps?sponsor=1
│     └── [email protected]
└── https://github.com/sponsors/ljharb
    └── [email protected]

As stated in the official npm documentation, the npm fund command shows funding information for the installed packages in your project.

And there can be a lot of them!

But you might wonder, how can you add funding information to your own project? It can be interesting to let know the world that you are looking for funding, right?

Adding Funding Links to Your `package.json`

It’s quite simple in fact. You can add funding information to your package.json file by using the funding field.

As stated in the official npm documentation:

You can specify an object containing a URL that provides up-to-date information about ways to help fund development of your package, a string URL, or an array of objects and string URLs:

{
  "funding": [
    {
      "type": "individual",
      "url": "http://example.com/donate"
    },
    "http://example.com/donateAlso",
    {
      "type": "patreon",
      "url": "https://www.patreon.com/my-account"
    }
  ]
}

From there, those who install your package might see the funding information when they run some npm commands. And who knows, they might decide to support your project!

On top of that, if your package is listed on the npm registry, the funding information will be displayed on the package’s page with a “Fund this package” button:

Funding your open-source project might be complicated, but referencing your funding links a the right places can make it easier for people to support you. And adding funding links to your package.json file is a good start! It’s not going to make hundreds of people support you, for sure, but it’s a good way to let the world know that you are looking for funding; and little by little, you might get a coffee or two out of it!

Get Real-Time GitHub Stars Notifications in Discord

Tue, 17 Sep 2024 00:00:00 GMT

After the refactoring of this website, folks (maybe you) started to spread the word about it. The statistics started to rise a little bit, and we discovered along the way that the repository holding this website also started to receive some new stars. To our knowledge, there’s no native way to get notified by GitHub when you receive stars on your repositories. So, we decided to do something about it!

We know, we know, tracking stars is a little bit linked to the gamification of the open source world, but to be honest, it’s still a fun way to keep track of your project’s popularity and engage with your community.

So, we decided to build a simple automation that would send a notification to a private Discord channel whenever our GitHub repository receives new stars. There are probably better ways to do this, existing solutions, but where is the fun in that?

After a few times of tweaking and testing, we finally got it working! 🎉

Here is the notification we received on our phone this afternoon:

And when you click on the notification, here is how the notification appears on Discord, showing the new star count and the repository name:

Cool, right? Here’s how it’s been done!

Step 1: Create a Discord Webhook

To send notifications to Discord, you will need to set up a webhook in your Discord server. Here’s how to do it:

Open your Discord server and navigate to the channel where you want to receive notifications. You can create a dedicated private channel for this purpose.
Click on the gear icon next to the channel name to access the channel settings.
Select the “Integrations” tab.
Click on “Webhooks” and then “Create Webhook.”
Give your webhook a name (e.g. “GitHub Stars Bot”), and select a nice image.
Copy the webhook URL, as you will need it later.

Here’s also a link to the Discord documentation - Intro to Webhooks for more information.

Step 2: Create a GitHub Repository

Now, let’s create a private GitHub repository to store our future GitHub Actions workflow. You can create a new repository or use an existing one, make it public or private, as you prefer.

Step 3: Create a Secret Variable in GitHub

To securely store your Discord Webhook URL to ensure that sensitive data isn’t exposed in your repository code, you will need to create a secret variable in your GitHub repository:

Go to your GitHub repository and click on the “Settings” tab.
In the left sidebar, click on “Secrets and variables” and then “Actions.”
Click on the “New repository secret” button.
Name your secret DISCORD_WEBHOOK_URL and paste the webhook URL you copied from Discord.

Step 4: Create a GitHub Actions Workflow

In this repository:

Create a new directory called .github/workflows.
Create a new file called for instance gh-stars-to-discord.yml (or choose a name you prefer).

The Algorithm

The algorithm is rather simple:

Every hour, the workflow will check the current number of stars on the repository using the GitHub API.
While doing so, it will also check the rate limit of the API.
- If the rate limit is low, the workflow will stop.
- If not, it will compare the current number of stars with the previous number of stars.
If there are new stars, it will send a notification to Discord using the webhook URL.
Finally, it will save the current number of stars for the next comparison.

Using the GitHub API

To get started, you will need to use the GitHub REST API to fetch the star count for your repository. The GitHub API provides a simple way to access information about your repositories, including the number of stars they have received.

There is a public endpoint that you can use to get the star count for a specific repository:

GET https://api.github.com/repos/{owner}/{repo}

Replace {owner} with your GitHub username and {repo} with the name of your repository. The response will include a JSON object with various details about the repository, including the stargazers_count field, which indicates the number of stars.

So for our main repository, you would make a request to:

GET https://api.github.com/repos/Open-reSource/openresource.dev

At the time of writing, Open {re}Source main repository has 61 stars, so the answer would be:

{
  // ...
  "stargazers_count": 61
  // ...
}

The Actual Workflow

Now, let’s create the actual workflow:

Clone your repository to your local machine or edit it directly on GitHub.
Add the following YAML code to your gh-stars-to-discord.yml file:

name: GitHub Stars to Discord

on:
  schedule:
    - cron: '0 * * * *' # Every 1 hour. You can change the frequency as needed.
  workflow_dispatch: # Allows manual triggering

env:
  DISCORD_WEBHOOK_URL: ${{ secrets.DISCORD_WEBHOOK_URL }}
  GITHUB_REPOSITORY: 'open-reSource/openresource.dev' # Change this to your repository

jobs:
  notify:
    runs-on: ubuntu-latest

    steps:
      - name: Get the current number of stars and check rate limit
        id: get_stars
        run: |
          response=$(curl -s -i https://api.github.com/repos/${{ env.GITHUB_REPOSITORY }})
          stars=$(echo "$response" | grep -oP '"stargazers_count":\s*\K\d+')
          rate_limit_remaining=$(echo "$response" | grep -Fi 'X-RateLimit-Remaining:' | awk -F': ' '{print $2}' | tr -d '\r')

          echo "Current stars: $stars"
          echo "Rate limit remaining: $rate_limit_remaining"

          echo "stars=$stars" >> $GITHUB_OUTPUT
          echo "rate_limit_remaining=$rate_limit_remaining" >> $GITHUB_OUTPUT

      - name: Stop if rate limit is low
        if: ${{ steps.get_stars.outputs.rate_limit_remaining < 10 }}
        run: |
          echo "Rate limit is low, exiting"
          exit 1

      - name: Cache previous stars count
        id: cache_previous_stars
        uses: actions/cache@v4
        with:
          path: previous_stars.txt
          key: stars-${{ github.repository }}-${{ github.run_id }}
          restore-keys: |
            stars-${{ github.repository }}-

      - name: Load the previous number of stars
        id: load_previous_stars
        run: |
          if [ -f previous_stars.txt ]; then
            echo "Loading previous stars"
            PREVIOUS_STARS=$(cat previous_stars.txt)
          else
            echo "No previous stars found"
            PREVIOUS_STARS=0
          fi
          echo "Previous stars: $PREVIOUS_STARS"
          echo "previous_stars=$PREVIOUS_STARS" >> $GITHUB_OUTPUT

      - name: Compare and notify if new stars
        if: ${{ steps.get_stars.outputs.stars != steps.load_previous_stars.outputs.previous_stars }}
        run: |
          NEW_STARS=${{ steps.get_stars.outputs.stars }}
          PREVIOUS_STARS=${{ steps.load_previous_stars.outputs.previous_stars }}
          if [ $NEW_STARS -gt $PREVIOUS_STARS ]; then
            echo "There are new stars: $NEW_STARS stars (previous: $PREVIOUS_STARS)"
            curl -H "Content-Type: application/json" \
              -d "{\"content\": \"The repository has gained new stars! Previous: $PREVIOUS_STARS → Total: $NEW_STARS\"}" \
              ${DISCORD_WEBHOOK_URL}
          else
            echo "No new stars"
          fi

      - name: Save current stars count
        run: |
          echo "${{ steps.get_stars.outputs.stars }}" > previous_stars.txt

      - name: Update cache with new stars count
        uses: actions/cache@v4
        with:
          path: previous_stars.txt
          key: stars-${{ github.repository }}-${{ github.run_id }}

Step 5: Run the Workflow

The workflow has a workflow_dispatch trigger, which means you can run it manually from the GitHub Actions tab in your repository. You can also wait for the next scheduled run (every hour) to see it in action.

The first time you run the workflow, it will probably send a notification saying that you had 0 stars and now you have X stars (the current number of stars).

To be honest, we are a little bit lazy, so we didn’t implement a complex logic to handle this first run, or even when the count of stars decreases. But you can always improve the workflow to suit your needs! This is just a starting point.

Automation is really cool! You could do the same thing for your followers in your GitHub profile, send notifications by email, Slack, etc. But automation is not limited to just notifications. You can also automate tasks like deploying your code, running tests, and much more.

The possibilities are endless!

A few words before we finish:

Want to spam us with stars? You can add some stars to https://github.com/Open-reSource/openresource.dev. We will be happy to get some notifications on our mobile phones!
Please let us know if you’d like to see more automation tutorials like this one!
We haven’t created a reusable workflow, shared it in the Marketplace, nor created a GitHub Gist. We thought it was easier just to share a little bit of code in this article that you could start from and adapt. If you want it to be stored somewhere with a more formal MIT license, please let us know! But please feel free to use it as you wish.

Happy coding! 🎉

Bluesky Starter Pack About Open Source

Mon, 01 Jul 2024 00:00:00 GMT

Bluesky released starter packs on June 26, 2024. They are personalized invites that allow users to bring people directly into your slice of Bluesky!

Bluesky, the decentralized social media platform, has recently introduced starter packs, aiming to personalize user experiences and make it easier for communities to grow. On June 26, 2024, Bluesky launched these starter packs, allowing users to bring friends directly into their customized Bluesky environment.

What’s in a Bluesky Starter Pack?

A Bluesky starter pack can include the following:

Custom feeds: On Bluesky, you can set any algorithm or topic as your home timeline.
Recommended follows: Add your favorite accounts and encourage new users to follow them.

At the time of writing:

Starter packs do not show up in search, so you will need to have someone send you the link or see the embed preview within the Bluesky app.
Starter packs can recommend up to 150 people and up to 3 custom feeds. New users will automatically have Following and Discover pinned.

The Open Source Bluesky Starter Pack

You can count on us! The Open {re}Source team is excited to introduce our very own Bluesky starter pack focused on open source! 🚀

We followed the tutorial provided by Bluesky in their blog post, but even without the tutorial, it is quite easy and intuitive to create a starter pack from the interface.

Below is the link to our open source Bluesky starter pack:

It contains accounts and individuals linked to the open-source world, as well as the Open Source feed we created for Bluesky.

Get Involved!

We hope you enjoy our starter pack! 🎉

Don’t hesitate to share your feedback with us on Bluesky, suggest new accounts to follow, or even create your own starter pack and share it with us! 🙌

Find this Bluesky profile widget cool? Check this out:

saurabhdaware/
bsky-widget Unofficial Bluesky widget to render cute profile cards in your website ^_^

Bluesky’s starter packs are an excellent way to foster community and personalize your social media experience. The Open {re}Source Bluesky starter pack is designed to connect you with the open-source community on Bluesky. Join us, and let’s continue to build and share together!

Feel free to reach out with any questions or suggestions. Happy Blueskying! 🚀

Who Is the Ghost User on GitHub?

Sat, 18 May 2024 00:00:00 GMT

This morning, I woke up to a storm of 200+ GitHub notifications. My inbox, usually pristine, was drowning in a deluge of spams.

As I scrolled through, my screen filled with an overwhelming array of spam discussions.

OK, cool, we are being productive today! 200+ GitHub discussions to delete!

We can’t see it in the screenshots, but there were several authors of the discussions, or answering to the discussions. I couldn’t block them for this specific repository as I am not the owner of the repository, but I could report them. So, one by one, I started to delete the discussions and report the users without looking at their profile.

The usual process happened on GitHub side, except for one user: ghost!

The GitHub Developer Support answered:

“The ghost username is in place to designate accounts that have been deleted by their owners, but that still have content that is visible across the GitHub platform.”

Oops!

Indeed, I didn’t check the GitHub profile of the user before reporting it, and it is pretty obvious when you are looking at it:

ghost Hi, I'm @ghost! I take the place of user accounts that have been deleted. 👻

The ghost user is a placeholder account used by GitHub to manage contributions and commits from users who have been deleted or whose accounts are no longer active. So it is not a spam account, and not especially an account to report. 😅

When a user is deleted from GitHub, their contributions, such as commits, issues, and comments, are not erased. Instead, these contributions are attributed to the Ghost user to maintain the integrity and history of the repository.

The Role of the Ghost User

The primary purpose of the ghost user is to preserve the history and context of projects.

It helps with maintaining repository integrity. When a user is deleted, removing their contributions would disrupt the continuity and understanding of the project. By attributing these contributions to the ghost user, GitHub ensures that the project’s history remains intact.

It also helps with contextual continuity. Comments on issues and pull requests often provide valuable insights and discussions. Reassigning these to the ghost user ensures that future contributors can still benefit from these historical discussions.

When Does the Ghost User Appear?

You might see the ghost user when a GitHub user decides to delete their account, all their contributions are transferred to the Ghost user.

It can also happen when GitHub removes an account due to policy violations or other reasons. In this case, the contributions are reassigned to the Ghost user.

In conclusion, the ghost user on GitHub is an essential mechanism to preserve the continuity and integrity of projects.

You can even follow it, it has already 9.5k followers! 😅

contrib.rocks: Generate an Image of GitHub Repositories Top Contributors

Sat, 27 Apr 2024 00:00:00 GMT

contrib.rocks is a an online tool that generates an image of the top contributors of a GitHub repository that can be embedded in any website or Markdown file; including its README file.

It is completely free and maintained by Suguru Inatomi, a.k.a. lacolaco. The source code is available on GitHub:

lacolaco/
contributors-img

This service allows to give a visual representation of the top contributors of any GitHub repository.

Generating such an image of your GitHub repository top contributors can be a great way to show the activity of your GitHub repository and encourage people to contribute, but also to celebrate your top contributors.

How to Use

Usage is pretty straightforward:

Go to https://contrib.rocks/
Enter a GitHub repository (e.g., open-reSource/openresource.dev)

And that’s it! You will get the image representing the top contributors of the GitHub repository you entered.

Then, you can click on the “Get Image URL!” button to get the Markdown code to embed the image in your README file for instance.

<a href="https://github.com/open-reSource/openresource.dev/graphs/contributors">
  <img src="https://contrib.rocks/image?repo=open-reSource/openresource.dev" />
</a>

Made with [contrib.rocks](https://contrib.rocks).

You will notice that the first part of the generated Markdown code is in reality HTML code. You can use this HTML code to embed the image in any website or Markdown file.

Rendering

Here is what it looks like for our openresource.dev GitHub repository:

Made with contrib.rocks.

And here is the same rendering, but on a more active repository like godot:

godotengine/
godot Godot Engine – Multi-platform 2D and 3D game engine

Made with contrib.rocks.

Some parameters can be added to the URL to customize the image:

max={number}: Max contributor count (100 by default)
columns={number}: Max columns (12 by default)
anon={0|1}: Include anonymous users (false by default)

So if we add &max=10&columns=2 to the image URL https://contrib.rocks/image?repo=godotengine/godot we get the following image with only the top 10 contributors and 2 columns:

<a href="https://github.com/godotengine/godot/graphs/contributors">
  <img src="https://contrib.rocks/image?repo=godotengine/godot&max=10&columns=2" />
</a>

Made with [contrib.rocks](https://contrib.rocks).

Made with contrib.rocks.

Repobeats: GitHub README analytics

Tue, 02 Apr 2024 00:00:00 GMT

Repobeats is a tool that provides analytics of a GitHub repository that can be embedded in any Markdown file; including its README file.

It is completely free and maintained by axiom.com, but does not seem to be an open-source project as it is not referenced in github.com/axiomhq.

This service allows to give a visual representation of the activity of your GitHub repository:

the number of contributions in the last 30 days
the number of opened/closed issues ratio with an associated bar chart of the past month
the number of PRs opened with an associated bar chart of the past month
the number of commits with an associated bar chart of the past month
the top contributors with their GitHub green square activity; their contribution heatmap

It can be a great way to show the activity of your GitHub repository and encourage people to contribute, but also to celebrate your top contributors.

Behind the scene, Repobeats uses public data available on GitHub.

Installation

Installing Repobeats requires a GitHub account.

To install Repobeats, it is pretty straightforward:

Go to https://repobeats.axiom.co/
Login with your GitHub account
Select the owner and repository you want to analyze

And that’s it! You will get a URL like ours that you can use in your README file or any Markdown file:

// Add the following to your README.md to embed Repobeats
![Alt](https://repobeats.axiom.co/api/embed/da1c940f0135aece8b9942f518b44dacc39bd9ce.svg 'Repobeats analytics image')

Rendering

Here is what it looks like for our openresource.dev GitHub repository:

And here is the same kind of data, but on a more active repository like freeCodeCamp:

freeCodeCamp/
freeCodeCamp freeCodeCamp.org's open-source codebase and curriculum. Learn to code for free.

freeCodeCamp is using it in the “Contributing” section of their README file and it looks great!

We can see right away that this repository is very active with a lot of contributions, issues, PRs, and commits.

GitHub Marketplace: Social Preview for Your GitHub Actions

Fri, 15 Sep 2023 00:00:00 GMT

You are finally ready to share your GitHub Action with the world. You have spent hours working on it, and now it is time to show it off. You open your favorite social media platform, start typing your post, link your GitHub Action on the GitHub Marketplace, click on send, and… your big face is on people’s screen!

This is what happened to me when I shared the marketplace link of my GitHub Action named “Update Issue Body”.

To be fair, the rendering is different and way better if one shares a link to the GitHub Action repository itself.

What Can We Do About It?

It is possible to add a social preview image to your GitHub repository. This image will be used when you share the link to your repository on social media platforms. But this image will also be used when you share the link to your GitHub Action on the GitHub Marketplace!

It is rather easy to do as everything is explained directly in the GitHub documentation Customizing your repository’s social media preview.

At the times of writing, images are recommended to be 1280x640px for best display on high-resolution devices.

While not visible in the documentation itself, GitHub provides in the settings of your repository a template for the social preview image which is pretty handy to get started and to have the safe zones.

I am not a designer, so I used the template to create my social preview image which has the following rendering:

How To Check If It Works?

After having uploaded the image to your repository, you can check if it works by using online tools like opengraph.xyz.

Whether you use the marketplace link or the repository link, you should see the social preview image.

Find This Template On Figma

Based on this rendering, I have created a reusable Figma template named “GitHub Actions and Repo Social Previews” that you can use to create your own social preview image.

Display Your Sponsors in Your GitHub READMEs

Thu, 18 May 2023 00:00:00 GMT

A simple nice way to reward your sponsors could be to showcase them in the projects you create on GitHub. And what a better place to do that than in your READMEs? This article will show you how to do that easily!

There are several ways to display your sponsors in your GitHub READMEs, but this article will focus on a single one by using SponsorKit created by Anthony Fu.

antfu/
sponsorkit 💖 Toolkit for generating sponsors images 😄

SponsorKit is a toolkit for generating sponsors images that supports GitHub Sponsors, Open Collective, Patreon, and Afdian.

Here’s how Anthony uses it himself in antfu/unplugin-auto-import README.

Let’s do our own sponsors image showcasing our GitHub sponsors!

Prerequisites

Before starting, you will need to have a GitHub account and have at least one sponsor.

Then, you will need to create a new GitHub personal access token (classic) with the read:org, and read:user scopes that you can name whatever you want, and keep its value somewhere for the next steps of this tutorial.

You can find more information about how to create a GitHub token in the GitHub documentation.

Create Your Repository

In order to facilitate the process, we have created for you a template repository that you can use to create your own repository: https://github.com/Open-reSource/sponsorkit-starter.

Open-reSource/
sponsorkit-starter Starter template for SponsorKit

From the Starter Template

You can click on the “Use this template” button to create your own repository.

Then, you will need to fill the form with the name of your repository, a description, and choose if you want to make it public or private. Click on the “Create repository from template” button to create your repository.

It will launch a GitHub Action that will fail, but don’t worry, we will fix that in the next steps.

From a New Repository

It is also possible to create your repository from scratch, clone it locally, and then running the following command:

npx degit Open-reSource/sponsorkit-starter

Configure Your Repository

Your new repository is now created, and should contain the following files:

.github/workflows/scheduler.yml that runs the SponsorKit action on a schedule every day, for each merge on the main branch, or manually.
.env.example as described in SponsorKit usage.
build.sh script to generate the sponsors images.
package.json relying on the latest version of SponsorKit and containing the build script.
sponsor.config.ts that contains the configuration for the generation of the sponsors images.

Change Default Permissions of GITHUB_TOKEN

First important thing to do is to change the default permissions of the GITHUB_TOKEN that is used by the GitHub Action to commit and push the generated sponsors images.

It can be changed by going to your repository settings, then to the “Actions” section, and choose “Read an write permissions” for the “Workflow permissions” option.

You can find more information about this configuration in the GitHub documentation.

Set up the environment variable

By looking at .github/worfklows/scheduler.yml, we can see that it relies on a ${{ secrets.SPONSORS_TOKEN }} environment variable.

We will need to set it up in the GitHub repository settings with “SPONSORS_TOKEN” as a name, and with the value of the GitHub personal access token that we have created in the prerequisites.

You can find more information about how to create a new repository secret in the GitHub documentation.

Configure the GitHub Action

Either after having cloned your repository locally, or directly on GitHub, you will need to edit the .github/worfklows/scheduler.yml to indicate your GitHub username as a value for “SPONSORKIT_GITHUB_LOGIN”.

Commit and push your changes.

Check Your Generated Images

This latter change will trigger the GitHub Action that will generate your sponsors images, commit, and push them at the root level of your repository with the message ” chore: update sponsors.svg”.

For example, you can see the generated sponsors images of the julien-deramond/static repository created from this same template.

(Optional) Generate The Images Locally

More information

It might be useful to know, even if rarely useful, it is also possible to run it locally.

You will need to install the dependencies by running npm i in your terminal.

Then, copy .env.example to .env still at the root level of your repository with the following content:

; GitHub provider.
; Token requires the `read:user` and `read:org` scopes.
SPONSORKIT_GITHUB_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx
SPONSORKIT_GITHUB_LOGIN=username

SPONSORKIT_GITHUB_TOKEN is the GitHub token you created earlier.
SPONSORKIT_GITHUB_LOGIN is your GitHub username.

The final step is to run npm run build in your terminal to generate the static files:

ju ߷ ~/j/static ➤ (main) npm run build                                                                                                                                                            (0.060674 hrs)
                                                                                                                                                                                                    17:48:16
SponsorKit v0.8.3

✔ Loaded from cache ./.cache.json                                                                                                                                                                   17:48:16
✔ Wrote to ./sponsors.json                                                                                                                                                                          17:48:16
ℹ Composing SVG...                                                                                                                                                                                  17:48:16
✔ Wrote to ./sponsors.svg                                                                                                                                                                           17:48:16
✔ Wrote to ./sponsors.png                                                                                                                                                                           17:48:16
                                                                                                                                                                                                    17:48:17
SponsorKit v0.8.3

✔ Loaded from cache ./.cache.json                                                                                                                                                                   17:48:17
✔ Wrote to ./sponsors.wide.json                                                                                                                                                                     17:48:17
ℹ Composing SVG...                                                                                                                                                                                  17:48:17
✔ Wrote to ./sponsors.wide.svg                                                                                                                                                                      17:48:17
✔ Wrote to ./sponsors.wide.png                                                                                                                                                                      17:48:17
                                                                                                                                                                                                    17:48:17
SponsorKit v0.8.3

✔ Loaded from cache ./.cache.json                                                                                                                                                                   17:48:17
✔ Wrote to ./sponsors.part1.json                                                                                                                                                                    17:48:17
ℹ Composing SVG...                                                                                                                                                                                  17:48:17
✔ Wrote to ./sponsors.part1.svg                                                                                                                                                                     17:48:17
✔ Wrote to ./sponsors.part1.png                                                                                                                                                                     17:48:18
                                                                                                                                                                                                    17:48:18
SponsorKit v0.8.3

✔ Loaded from cache ./.cache.json                                                                                                                                                                   17:48:18
✔ Wrote to ./sponsors.part2.json                                                                                                                                                                    17:48:18
ℹ Composing SVG...                                                                                                                                                                                  17:48:18
✔ Wrote to ./sponsors.part2.svg                                                                                                                                                                     17:48:18
✔ Wrote to ./sponsors.part2.png

All the images are now generated at the root level of your repository. You can check them out in your file explorer.

Warning: Once it’s done, please don’t forget to remove at some point your GitHub token from the .env file for security reasons. You won’t probably never re-run it from your local machine.

Use the Generated Images in Your READMEs

Now that the GitHub Action has run, you can use the generated images in your READMEs.

For example, you can use the sponsors.svg image in your README.md file by adding the following code. Don’t forget to replace username by your GitHub username in the link’s href, link’s aria-label, and image’s src attributes.

<p align="center">
  <a href="https://github.com/sponsors/username/" aria-label="Go to username's sponsors page">
    <img src="https://cdn.jsdelivr.net/gh/username/static/sponsors.svg" />
  </a>
</p>

Warning: GitHub can take a while to render the image in your README. If you don’t see it, wait and refresh the page. On my side, it took around 10 minutes to be displayed. As long as the https://cdn.jsdelivr.net/gh/username/static/sponsors.svg URL is showing the image, don’t worry, it will be displayed in your README soon.

Final Result

You can check my own personal sponsors list generated by following this article:

And find it integrated in one of my projects: https://github.com/julien-deramond/update-issue-body#sponsors.

Can I Take This Issue?

Mon, 15 May 2023 00:00:00 GMT

Open-source software development is a collaborative effort that relies on volunteers to contribute to the project. Contributors have different skill levels and come from various backgrounds. As such, project maintainers have a crucial role in ensuring that the contributions received are of high quality and meet the project’s goals. One way maintainers do this is by providing clear guidelines on how contributors can submit their work. Unfortunately, contributors don’t always take the time to read these guidelines, and maintainers don’t always assign issues, which can lead to confusion and frustration on both sides. In this article, we’ll explore the issue of unassigned contributions and discuss what can be done to address it.

So Can I Take It or Not?

Contributor

Hey! Can I take this issue?

Maintainer

Hello! As mentioned in our contributing guidelines, we do not assign issues in this repository. However, if you’d like to contribute a solution, feel free to create a PR directly. Thank you for your interest!

Contributor

OK thanks!

This is a common scenario in open-source projects. A contributor sees an issue that they think they can solve, so they ask if they can take it.

Maintainer

Seriously, again… What do I usually answer? Hmmm…

If you are the maintainer of this open-source project, you start by receiving a notification. You then go to the issue and take the time to respond to the contributor something you may have already said ten times this week. You then go back to your work, and receive another notification from the same contributor saying basically “OK thanks!”.

Contributor

Seriously? I have already checked the issue, I have the solution!!! They don’t trust me. They think I’m not good enough, they don’t deserve my contribution…

If you are the contributor, you may feel frustrated. You may have spent time looking for an issue to work on, and you may have even started working on it. You then ask if you can take it, and the maintainer responds by saying that they don’t assign issues. You then feel discouraged and decide not to contribute to the project.

This is a frustrating experience for both the contributor and the maintainer.

The contributor is left wondering if they can actually work on the issue, and the maintainer is left wondering why the contributor didn’t read the contributing guidelines.

Why Do Some Maintainers Assign Issues?

Maintaining an open-source project is a challenging task that involves multiple responsibilities. One of them is managing issues reported by contributors or users. Assigning issues to specific maintainers or contributors is a common practice that can help ensure that problems are addressed in a timely and efficient manner and that contributions align with the project’s vision and goals. However, not all maintainers assign issues, or they may only assign a small number of them. In this part, we will explore the reasons why some maintainers choose to assign issues and what are the benefits of assigning issues.

Efficiency

Assigning issues to specific individuals helps ensure that they are addressed promptly and efficiently, reducing the likelihood of issues being overlooked or forgotten. It allows maintainers to manage issues more efficiently, ensuring they are resolved in a timely and effective manner. However, the assignee can still benefit from the feedback of the community and maintainers, and this approach is particularly useful for larger projects that receive many issues.

Accountability and Responsibility

Assigning issues can help to clarify the responsibilities of different contributors and maintainers. It’s clear who is responsible for resolving an issue when it’s assigned to a specific person. This can reduce confusion and ensure that issues are addressed by the right people. In larger projects, where multiple contributors and maintainers may be working simultaneously.

Assigning issues can also create a clear sense of accountability and responsibility. When an issue is assigned to a specific person, they become responsible for resolving it. This accountability can motivate contributors and maintainers to take ownership of the issue and work towards a solution. When contributors know that they are responsible for resolving an issue, they are more likely to focus their efforts on finding a solution. This sense of ownership can also lead to a more engaged and invested community.

Encouraging Contributions

Assigning issues to specific contributors can foster community involvement and collaboration. Assignees have a clear understanding of what needs to be done, leading to increased contributions and a more active community. Additionally, assigning issues can encourage collaboration between contributors and maintainers, leading to more efficient issue resolution and a stronger sense of community.

To address unassigned contributions, both contributors and maintainers need to work together.

Contributors can help by taking the time to read the project’s contribution guidelines carefully. They should also review the issue tracker and try to find issues that align with their skills and interests. If an issue is not assigned, contributors can reach out to maintainers or community managers for guidance.

Maintainers can also take steps to address unassigned contributions. One way is to review the issue tracker regularly and assign issues promptly. They can also update the contribution guidelines and make them more visible to ensure that contributors are aware of them. Maintainers can also provide feedback on contributions, highlighting areas for improvement and encouraging contributors to continue their work.

Better Resource Management

Assigning issues can also help to manage resources more effectively.

By assigning issues to specific contributors or maintainers, the workload can be distributed more evenly. It also helps prevent duplicated work, as contributors can see what others are working on and avoid duplicating their efforts.

Assigning issues can also help maintainers to manage their workload. By assigning issues to specific people, maintainers can ensure that they are not overwhelmed with too many tasks at once.

This approach can help to prevent burnout and ensure that contributors and maintainers are working on issues that are within their skill level and expertise. It can ensure that maintainers’ time and energy are focused on the issues that matter most.

Avoiding Confusion

Assigning issues can also help to avoid confusion. When multiple people are working on the same issue, it can be difficult to know who is responsible for what. By assigning issues to specific people, maintainers can ensure that everyone knows what they are responsible for and what their role is in addressing the issue.

Why Do Some Maintainers Not Assign Issues?

Despite the benefits of assigning issues, there are also some challenges that maintainers may face. So there are some maintainers who choose not to assign issues, quite a lot in fact. This lack of assignment can result in contributors not knowing what to work on or feeling discouraged about contributing to the project. In this part, we will explore the reasons why some maintainers do not assign issues, or sometimes only a small amount of them.

Limited Resources

Maintaining an open-source project can be a daunting task, and the responsibility is often shouldered by a handful of maintainers. These maintainers are responsible for reviewing contributions, triaging issues, and coordinating with contributors to ensure the project’s growth and success. However, due to limited resources, some maintainers may not be able to assign issues effectively, which can lead to frustration among contributors and a decline in the project’s growth.

Maintaining an open-source project requires a significant amount of time and effort, and it can be a voluntary and unpaid job for many maintainers. As such, they may not have the financial resources or personnel to manage every issue that is reported.

Assigning an issue without proper analysis and discussion is inadequate and can impede its development. This is especially true for issues coming from the community, as they may lack sufficient details. Prioritizing, analyzing, and discussing the issue is necessary before assigning it to a maintainer or contributor for resolution. Assigning issues to specific people requires time and effort, and some maintainers may prefer to focus their attention on other aspects of the project, such as code review or documentation. Furthermore, some maintainers may be juggling multiple projects or other commitments in their personal and professional lives, which can limit their ability to assign issues.

They are often already too busy reviewing contributions. Open-source projects are often community-driven, and they can receive a large number of contributions, especially when they gain traction. Each contribution requires review, testing, and integration, which can be time-consuming, especially for maintainers who have other responsibilities. In such cases, maintaining the project can become a daunting task, and maintainers may be unable to keep up with the influx of contributions, leading to a backlog of unassigned issues and sometimes even unassigned pull requests.

The issue tracker can become overwhelming, making it difficult to assign issues to the right people. The issue tracker serves as a central hub for the project’s issues, feature requests, and pull requests. As the project grows, the number of issues and pull requests can quickly pile up, leading to confusion on the part of contributors. Without proper triaging and assignment, contributors may not know what to work on or feel discouraged about contributing to the project, resulting in a decline in contributions.

Large Communities

As the community expands or is already large, maintainers may struggle to keep track of all its members and their capabilities. In such cases, assigning issues can become a daunting task, as maintainers may be uncertain of the skill level and commitment of potential contributors. Junior developers and new open source members may be attracted to issues in already popular projects, seeking mentorship and opportunities to contribute, but this can overwhelm maintainers who cannot mentor everyone or have limited resources for reviewing contributions.

To assign issues appropriately, maintainers may need to review past contributions, evaluate code quality, and reach out to potential contributors to discuss their interest in the project. However, this can be a time-consuming process, leading some maintainers to avoid assigning issues altogether. This can create a backlog of issues that go unaddressed, causing frustration among contributors.

And this approach can backfire, as it can create a backlog of issues that are not being addressed, which can cause frustration among contributors. In such cases, it is essential to establish clear guidelines for issue assignment and ensure that all members of the community are aware of them.

Collaborative Approach

Some maintainers believe that assigning issues can create silos and discourage collaboration. They may prefer to have an open forum where anyone can contribute to resolving issues. This approach allows the community to work together and share knowledge and expertise. They encourage contributors to take ownership of the project and work together to resolve issues, rather than relying on a single maintainer to manage all aspects of the project.

While this approach can be effective, it can also result in a lack of direction and oversight. Without clear guidance or leadership, contributors may not know what to work on or how to approach a particular issue.

To address this, maintainers can provide clear documentation on the project goals and how to get involved. Additionally, they can establish communication channels for contributors to ask questions or provide feedback, or even encourage contributors to work in pairs or small groups to resolve issues. Another potential solution is to use a rotating ownership model, where issues are assigned to a specific contributor for a set period of time, after which ownership of the issue rotates to another contributor. This approach allows for individual ownership of issues while still promoting collaboration and knowledge-sharing.

By doing so, maintainers can foster a collaborative environment while still maintaining some level of oversight and direction.

Avoiding Favoritism

Assigning issues can also lead to accusations of favoritism or bias. Some maintainers may choose not to assign issues to avoid any perception of preferential treatment. By allowing anyone to work on any issue, maintainers can ensure that everyone has an equal opportunity to contribute. This approach can help to create a more inclusive and welcoming community, where all contributors are valued and respected.

However, this approach can also result in confusion and duplication of effort. If multiple contributors are working on the same issue, it can lead to wasted time and resources.

One way to ensure that everyone has a fair opportunity to contribute to a project is through establishing clear guidelines and protocols for contribution. For instance, the project can have a clearly defined process for claiming issues, stating who is responsible for which tasks, and how contributors can go about resolving issues. This approach allows contributors to work together in a coordinated fashion and avoid duplication of effort. In some cases, it may even foster a sense of friendly competition amongst contributors, which can help to drive innovation and progress.

They can also provide feedback on contributions to ensure that everyone is working towards the same goal, thus minimizing duplication of effort and confusion.

Trust Community

Another reason why some maintainers do not assign issues is that they trust the community to self-organize and take ownership of issues without assigning them to specific individuals. This approach is based on the belief that a highly engaged and motivated community will work together to resolve issues and prioritize tasks. It can be an effective approach in projects with a large and active community where multiple contributors can work on the same issue simultaneously.

When maintainers trust the community to self-organize, they can focus on other aspects of the project such as developing new features, maintaining documentation, or mentoring new contributors. This approach can also be useful in situations where maintainers have limited resources or are unable to keep up with the volume of incoming issues. By allowing the community to take ownership of the project, maintainers can create a sense of ownership and belonging within the community, leading to increased participation and collaboration.

However, relying solely on the community to self-organize can also have its drawbacks. Without clear guidance or leadership, contributors may not know how to prioritize tasks or resolve issues effectively. Sometimes, the issues are not yet read by the maintainers and contributors start the development of something useless which is not what the maintainers want. This can result in duplication of effort, wasted time and resources, and may lead to frustration and disengagement among contributors.

To address these issues, maintainers can establish clear guidelines on how to claim an issue and work on it. They can also provide feedback on contributions to ensure that everyone is working towards the same goal. Additionally, maintaining open communication channels for contributors to ask questions or provide feedback can help foster a collaborative environment while still maintaining some level of oversight and direction.

Lack of Familiarity

We may tend to forget it but not all the maintainers know everything about open source so some maintainers may “choose” not to assign issues simply because they are not familiar with the process. Assigning issues can be a complex task, especially in large projects with many contributors. If a maintainer is not comfortable with the process, they may choose to avoid it altogether. Additionally, some maintainers may be new to the project and may not yet have a good understanding of the various roles and responsibilities. This can make it difficult to assign issues to the appropriate parties.

In this case, this article may be a good starting point 🙂

Hybrid Approach

An open-source project can be maintained by a core team working full-time, often linked to a company. Then, issues assignments may be handled differently than in other open-source projects. Indeed, they can rely on a specific agenda and deadlines, so they may assign issues to ensure accountability, clear ownership, prioritization, expertise, and consistency. At the same time, the core team may also allow external contributors to contribute to the project for diverse perspectives, community building, increased productivity, and learning opportunities. In that case, they could not assign issues to external contributors. Here comes our hybrid approach.

As an external contributor, you won’t probably be assigned to an issue for several reasons:

The issue must be tackled soon and they can’t rely on an outsider to deliver a specific task with a deadline.
The issue requires extra internal information the contributor can’t have access to or internal discussions that happened or will happen and are not tracked, or won’t be tracked in the repository.

However, it might happen, depending on their contributing guidelines, for unprioritized issues that don’t have any deadline yet. Most repositories use a dedicated label in this case to let know outsiders that they can help and contribute. And of course, they will probably be happy to review code not related to already planned issues or fixes.

By allowing external contributions to the project, the core team might benefit from:

A wide range of new perspectives and ideas.
Building a community around the project.
Increasing productivity by leveraging the contributions of others.
Recruiting members of the community.
Learning from the contributions of others and improving their own skills and knowledge.

How to Address the Issue of Not Assigning Issues

Not assigning issues is a choice made by the maintainers based on several criteria as seen in the previous sections.

Strong Workflow

To counter-balance the fact that issues are not assigned, projects often rely on a strong issues workflow with a powerful system of labeling and triage to help identify the complexity of the tasks, the status of the analysis, whether the issue is ready to develop or not, the target versions, the scope, etc. so that the community can be autonomous, but also to reduce the noise for the maintainers who have most of the time really limited resources.

This full backlog can be accompanied by a schema representing the whole workflow of states of issues and sometimes even pull requests, the actors, etc. It can be linked to a roadmap.

To make the most of their limited resources, maintainers can set up automatic triage systems that categorize and prioritize issues based on their severity or complexity so that the community can be autonomous and evaluate where they could be helpful depending on their level and expertise. High-priority or high-complexity issues can be tackled by experienced contributors or reserved for the core team while low-priority or low-complexity might be left for the new contributors to help them gain experience.

Additionally, maintainers can reach out to the community to encourage contributions and provide guidance on how to best help with the project so that the whole process runs smoothly. By doing so, maintainers can ensure that they are making the most of their limited resources, while also making it easier for contributors to get involved.

Labeling is very powerful as it can filter the backlog by elements but also be used for automation in projects.

Everything can start from the creation of these issues with the issues templates to guide contributors in providing the necessary information when they create an issue. This can include a checklist of requirements that need to be met before an issue can be treated, such as providing a clear description of the problem, steps to reproduce, any relevant logs or errors messages, or motivation if this is a new feature.

At the time of writing, GitHub doesn’t provide any options to add some Markdown content at the end of the issues when using issue templates. However, you can use GitHub Actions to do that. Here is an example of a GitHub Action that adds a message for newly created issues:

Open-reSource/
labs-append-markdown-to-issues [Labs] Automatically append Markdown to issues

An infinite way of managing labels is possible. Let’s imagine, for example, a to analyze label that can be picked up only by a core team member. When this core team member analyzed the issue and provided expectations, clarity, and guidance, the label could be transformed into an analyzed label, and a new ready for dev label could be applied combined to high priority and low complexity labels, and a version 12 label, bug or feature, core team if it is reserved for the core team, or pr welcome when it is OK for external contributors to work on it. When doing that, contributors can start to help or not, filter the backlog by labels, and the core team can focus on the most important issues. If the workflow is automated, the issue can go to one or another project, be in a roadmap, etc. This is just an example, but you can imagine how powerful it can be.

Communicate Clearly

By establishing clear communication channels, maintainers can provide guidance to contributors and answer any questions they may have about the assignment process and issues workflow. This can also help build trust and foster a sense of community among contributors, which can lead to greater collaboration and more successful outcomes.

By taking the time to establish clear guidelines and protocols for issues assignment and maintaining open communication with contributors, maintainers can help ensure that each issue is addressed by the most qualified contributor, leading to more successful outcomes for the project as a whole.

Whether maintainers put in place a simple or advanced workflow, it must be clearly explained somewhere. Depending on the amount of information, it can be directly in the Contributing Guidelines or in a Wiki, documentation, etc. linked from the Contributing Guidelines.

If issues are assigned, make sure that it’s clearly explained in the Contributing Guidelines.

If issues are not assigned, make sure that it’s clearly explained in the Contributing Guidelines.

The Importance of Contribution Guidelines

Yes, it is important for open-source projects to have Contributing Guidelines to provide critical information about the project, including its goals, coding standards, how to submit changes, how to ask for help, and how to get involved in the community.

This is also the place where are explained how contributors can report issues and how maintainers will manage them. The guidelines should include information on whether issues will be assigned or left unassigned, and why. This will help to set expectations for both contributors and maintainers and ensure that everyone is on the same page.

If an open-source project is maintained by a core team working for a company, the contribution guidelines should make it clear that issues will be managed by the core team and may or may not be assigned to individual team members. The guidelines should also explain the reasons behind this approach, such as the need to ensure that issues are addressed in a timely and efficient manner, and the fact that the core team has the expertise and resources to manage the project effectively.

If an open-source project is maintained by a community of volunteers, the contribution guidelines should explain how issues will be managed and whether they will be assigned or left unassigned. The guidelines should also provide guidance on how contributors can help to manage the issue tracker, such as by reviewing and triaging issues, and how they can get involved in the project’s decision-making process.

Regardless of the approach taken by an open-source project, it’s important to have clear and transparent contribution guidelines that set expectations for both contributors and maintainers. This will help to ensure that the project is sustainable and that issues are addressed in a timely and efficient manner. On top of explaining what is the process, it is also interesting to explain why this choice has been made by the maintainers. It will help contributors who will read the contributing guidelines, but can also be useful to remind this rule for those who don’t read the contributing guidelines. It happens sometimes, isn’t it? ;)

Often, contributors don’t read the contributing guidelines

First of all, contributors may not even know their existence. Always remind that each day, there are newcomers in the open source world who don’t know how it works. But let’s be honest, apart if the Contributing Guidelines are not at the right place, contributors don’t always take the time to read them because they may be in a hurry to start working on the project, or because they assume that their previous experience will suffice.

So the frustration of maintainers can be understood rather easily, especially if they spent time writing down a thorough explanation of why the repository doesn’t assign issues. Reminding days after days for years that the repository doesn’t assign issues feels like repeating over and over the same thing. But always remind that you are not talking to the same person who has a different background regarding OSS and probably does not have the same expertise as you in the field.

Streamers, for example, use pre-defined messages, videos, or FAQs in order not to repeat the same information to the newcomers (who almost always ask the same things based on the streamer’s point of view) so that they are not bothered when they are streaming, and the viewers can still have the information. Having tools answering for you, either semi-automatic or automatic, will help not become angry at contributors after repeating the same thing over and over.

In a nutshell:

Make the Contributing Guidelines clear and easy to find. Ensure that they are prominently displayed on the project’s website, README file, in the documentation, in the issues templates, etc. Make sure they are easy to read and understand, with clear instructions on how to contribute and how the issues are handled in the global workflow.
Communicate clearly with contributors. Even if it is mentioned everywhere, always remind nicely this information to the contributors who make mistakes. Provide clarity and guidance.
Be consistent. Ensure that the rules for assigning issues are consistent across the project and that all maintainers are aware of them. This can help prevent confusion and ensure that all contributors are treated fairly. Having a unique reference stored in only one place is really handy because maintainers will be able to link this reference instead of reinterpreting the content every time, and maybe not being consistent. Plus, it’s always true even if the reference changes.
Consider revisiting the guidelines. If you find that many contributors are not following the guidelines, it may be worth revising them to be clearer or to better reflect the needs of the project. However, be sure to communicate any changes clearly to existing contributors and provide guidance on how to adjust their contributions accordingly.

Overall, the key is to be patient, clear, and helpful in your interactions with contributors. By doing so, you can create a welcoming and productive community around your open-source project

Manual, Semi-automatic, and Automatic Tools

Overall, by using a combination of manual, semi-automatic, and automatic tools, maintainers can help to manage the influx of questions from contributors who are unsure about taking up an issue. This can help to ensure that contributors are able to contribute effectively and that maintainers can focus on other aspects of the project.

There are several manual and automatic tools that maintainers can use to help handle these questions and politely refuse them by mentioning the contribution guidelines.

Direct communication is not really a tool, but this is often the way it is handled by maintainers. They can engage with contributors who are unsure about taking up an issue, write down a specific personalized message, help clarify any confusion and ensure that contributors feel supported and empowered to contribute in the right way, and even provide alternative issues or areas of the project where the contributor can help. But it takes a huge amount of time, especially in a big community, and the content can be inconsistent.

In most of the Git source code platforms, it is possible to set up saved replies:

It is only a semi-automatic tool but it can help save a lot of time by not repeating over and over the same thing. Maintainers will lose the personalized side but will gain consistency with a clear and precise answer accompanied by links pointing to unique resources.

If you are maintaining OSS projects or communities on different platforms, you may opt for decentralized messages and actions stored in your own environment for transversal usage. Tools like Alfred on macOS could be used in this spirit.

Writing this article was the occasion to try creating a semi-automation tool based on labels. Maintainer can add a we don't assign issues label to an issue right after a comment asking to be assigned. This label will trigger a GitHub action that will write a personalized comment explaining that the repo is not handled that way, and then remove this label automatically. We could even hide the original contributor’s comment in the process.

The source code of this experiment is available on GitHub via the card below.

Open-reSource/
labs-we-don-t-assign-issues [Labs] "we don't assign issues" label that writes a comment and is then auto-deleted

Unfortunately, if there are intermediate comments before maintainers have the time to use this label, it won’t work. And it stays semi-automatic.

This was a nice experiment, but can we go further with full automation? Actions can already be triggered when a comment is created or updated, it would only be a matter of time to create a bot that would be able to answer automatically to the contributor.

We keep seeing new AI tools popping up every day in our feeds. They are pretty powerful and help automation. But so far, we haven’t had the occasion to find or test such tools for this specific use case. If you have any suggestions, or links, you can create an issue so that we can test them and improve this article. Or come talk about it on our Discord.

How to Create a Code of Conduct for an Open-Source Project

Thu, 13 Apr 2023 00:00:00 GMT

Creating a code of conduct is an essential step in ensuring a safe and welcoming community for an open-source project. In many cases, the code of conduct may be created before the community even exists. This can be beneficial as it ensures that the project starts with clear expectations and guidelines for behavior. The process of creating a code of conduct involves several steps, including defining goals and scope, researching existing codes of conduct, drafting the document, reviewing and approving the document, publishing and communicating the code of conduct, and regularly reviewing and updating the document.

Why do we need one?

By adopting a code of conduct for your open-source project, you can establish clear expectations for participant behavior, which can help foster a positive social atmosphere within your community. In turn, this can not only protect your participants, but also yourself as the project maintainer, as unproductive attitudes from participants can ultimately make you feel drained or unhappy about your work. By being proactive and enforcing a code of conduct, you can facilitate healthy and constructive behavior, which can reduce the likelihood of issues arising and make your project a more welcoming and supportive environment for all.

Define the Goals and Scope

The first step is to define the goals and scope of the project. This involves considering the project’s purpose, its intended audience, and the types of behavior that are expected from contributors and users. The goals of the code of conduct should be clear and concise and should outline the expectations for all contributors, users, maintainers, and community members.

Defining the goals and scope of a project is the first step in creating a code of conduct. This involves identifying the project’s purpose, intended audience, and expected behavior from contributors and users. The code of conduct should have clear and concise goals that outline the expectations for all community members, including contributors, users, and maintainers.

Additionally, a code of conduct should also specify where it applies, who it applies to (including sponsors), what actions will be taken if someone violates it, and how individuals can report any violations. Considering “where it applies”, we are often thinking only about issues, pull requests, and discussions, but it can apply also to community events, social media, communication applications, etc.

Research Existing Codes of Conduct

Whether the community already exists or not, the next step is to research existing codes of conduct to identify what works and what doesn’t, but also to have a base to work on. This can be done by reviewing codes of conduct from similar projects or industries. The goal is to identify best practices and guidelines that can be incorporated into the code of conduct.

Contributor Covenant

The Contributor Covenant is a widely-used code of conduct to free and open-source software projects, created by Coraline Ada Ehmke in 2014. This code of conduct outlines specific behaviors that are expected from contributors, such as being respectful of differing viewpoints, avoiding offensive language, and refraining from harassment or discrimination. The goal of the Contributor Covenant is to ensure that everyone can participate in open-source projects without fear of being marginalized or excluded and to promote a culture of kindness and empathy in the tech industry.

It has been adopted by thousands of open-source projects and many prominent companies including Google, Intel, GitLab, and open-source projects including Vue.js, Symfony, Bootstrap. The code outlines specific behaviors expected of contributors, such as being respectful of differing viewpoints and avoiding offensive language. In 2021, it has been included in the Organization for Ethical Source. The Contributor Covenant has played a significant role in promoting a culture of kindness and empathy within the open source community.

Adopting the Contributor Covenant as your code of conduct offers several benefits:

It is widely recognized within the community, meaning that the values of the community can be instantly communicated and understood.
It has been reviewed and adopted by many which makes it a trusted and reliable option.
If you are unsure about how to create your own code of conduct, the Contributor Covenant is readily available and can provide a practical starting point for creating conduct that reflects the values of your community.
It has been translated into multiple languages, making it accessible and inclusive for a diverse range of contributors.

Other Existing Codes of Conduct

There are several other well-known codes of conduct in open source, in addition to the Contributor Covenant, or based on it. Here are a few examples:

The Ubuntu Code of Conduct;
The Mozilla Community Participation Guidelines with a very interesting explanation:
“These guidelines have been adapted with modifications from Mozilla’s original Community Participation Guidelines, the Ubuntu Code of Conduct, Mozilla’s View Source Conference Code of Conduct, and the Rust Language Code of Conduct, which are based on Stumptown Syndicate’s Citizen Code of Conduct. Additional text from the LGBTQ in Technology Code of Conduct and the WisCon code of conduct. This document and all associated processes are only possible with the hard work of many, many Mozillians.”
The Django Code of Conduct;
The Rust Code of Conduct adapted from the Node.js Policy on Trolling as well as the Contributor Covenant v1.3.0;
The CNCF Code of Conduct adapted from the Contributor Covenant v2.0;

These are just a few examples of the many codes of conduct that exist in the open source community. Each code of conduct may have its own unique focus and guidelines, but they all share the goal of promoting a respectful and inclusive environment for collaboration and contribution.

Draft the Code of Conduct

After gathering research and input, the code of conduct can be drafted. The code of conduct should be written in clear and concise language and should be easily understood by all members of the community.

It should include guidelines on behavior, as well as consequences for violating the code of conduct.

It’s crucial to specify the actions that will be taken if there is a violation of the code of conduct. Doing so will convey the seriousness with which you take the code of conduct, assure the community that complaints will be fairly and transparently reviewed, and demonstrate your commitment to enforcing the code of conduct. Providing a private way for people to report violations and specifying who will receive those reports are also essential. Lastly, it’s important to offer an alternative option for people to report violations if they are related to someone who receives those reports.

Review and Approval

Once the code of conduct is drafted, it is important to review it with key stakeholders, including legal advisors in some cases, and any other relevant parties. These individuals could provide feedback on the code of conduct and ensure that it is legally sound.

Publication and Communication

Once the code of conduct is finalized, it should be published and communicated to the community.

This can be done through the:

project’s website or documentation
- with a link in the footer or elsewhere to a code of conduct stored anywhere.
- by creating a dedicated page like in GitLab Code of Conduct.
other communication channels like Slack, Discord, Mattermost, etc..
- In Astro Lounge Discord, they have it for example in their “rules” channel which contains a link to their code of conduct stored on GitHub.
source code repositories.
- For open-source projects, this is mainly where you’re going to find it at the root level of the main repository of the organization.

It is important to ensure that all members of the community are aware of the code of conduct and understand its expectations. But it is also important to have it available accessible by anyone and in order to link it if one must be reminded of the rules.

How to add it to source code repositories

GitHub Provides Some Templates

GitHub offers guidance on creating a Code of Conduct through templates available on their website. When adding a new CODE_OF_CONDUCT or CODE_OF_CONDUCT.md file through the interface at the root level of your repository, you can select from two different templates to add to your project:

Contributor Covenant;
Citizen Code Of Conduct;

You can then complete your code of conduct by filling out a simple form with the required information.

After reviewing your changes, submit them and a CODE_OF_CONDUCT.md file will be created at the root level of your repository. You can then view a special display by visiting your repository. An example of this rendering can be seen in the GitHub Community repository.

This article may be obsolete in the future regarding some details, please check the latest version of the GitHub documentation for Adding a code of conduct to your project.

Manually

Adding a code of conduct in your repository is a straightforward process that works for all source code repository services, including GitHub, GitLab, BitBucket, and more. Simply create a CODE_OF_CONDUCT or CODE_OF_CONDUCT.md file at the root level of your repository, depending on whether you prefer the Markdown or simple text format.

While GitHub provides guidance with templates, you can in fact use any code of conduct you prefer. Except for GitHub, even if most of the source code repository services do not offer a dedicated display in repositories for code of conduct files, it is still crucial for open-source projects to incorporate one, as it is considered a best practice. By storing it at the root level of the project, it can be easily referenced and used as a standard for appropriate behavior within the community.

If you have selected the Contributor Covenant as your code of conduct, there is a neat trick to add a badge to your README.md file. You can do this by adding the following code:

[![Contributor Covenant](https://img.shields.io/badge/Contributor%20Covenant-2.1-4baaaa.svg)](code_of_conduct.md)

Reusable Code of Conduct in GitHub

GitHub provides a convenient feature for reusing a code of conduct across multiple repositories by creating a default code of conduct. This default code of conduct is part of a list of default community health files, including CONTRIBUTING, FUNDING, and issue and pull request templates. Any repository owned by the account that does not have its own code of conduct file will use this default one. To set this up, you can create a .github public repository and add a CODE_OF_CONDUCT or CODE_OF_CONDUCT.md file at the root level of the repository.

To see an example of how this works, you can take a look at our .github public GitHub repository.

This article may be obsolete in the future regarding some details, please check the latest version of the GitHub documentation for Creating a default community health file.

Regular Review and Updates

Finally, the code of conduct should be reviewed and updated regularly to ensure that it remains relevant and effective. This review process should involve the entire community and should be conducted at regular intervals, such as annually.

A useful tip for those using the Contributor Covenant is to subscribe to release notifications in project’s GitHub repository. This way, you can easily stay informed and be alerted when a new version of the code of conduct is released, ensuring that your project stays up-to-date.

Enforcing the Code of Conduct

It’s rare, but in any community, there may come a time when a member violates the code of conduct. When this happens, there are several steps that moderators or maintainers can take to address the situation.

The first step is to gather information about the situation. It’s important to treat each community member’s voice as important as your own and take any reports seriously. Investigate the matter even if it doesn’t match your own experience with that person. Before responding, take time to understand what happened by reading through the person’s past comments and conversations to better understand who they are and why they might have acted in such a way. Try to gather perspectives other than your own about this person and their behavior.

Once you have gathered sufficient information, it’s important to take appropriate action. Remember that your goal as a moderator or maintainer is to foster a safe, respectful, and collaborative environment. Consider not only how to deal with the situation in question, but how your response will affect the rest of your community’s behavior and expectations moving forward. Depending on the severity of the violation, you may choose to give the person in question a public warning and explain how their behavior negatively impacted others or privately reach out to the person to explain how their behavior negatively impacted others. In some cases, stronger action may be necessary, such as suspending or permanently banning the person from the project.

Open {re}Source | Articles

Running a Local AI Inside Obsidian with Ollama

Why Local AI in a Notes App?

What We’ll Build

Step 1: Install and Test Ollama (Command Line First)

Step 2: Install the Required Obsidian Community Plugins

AI Providers

Local GPT

Step 3: Attach Hot Keys for Quick Access

Step 4: Test Local GPT Inside Obsidian

Using the Context Menu

Using the Action Palette

Everyday Use Cases That Actually Feel Useful

Trade-Offs (And Why They’re Worth It)

Coding LinkedIn Carousels

How LinkedIn carousels work

The Idea

How to Code LinkedIn Carousels

We Created a Theme for LinkedIn Carousels

How to Use the Theme

Add Funding Links to Your 'package.json'

Funding Open-Source Projects?

Packages Are Looking for Funding

You Can Turn It Off, by the Way

npm fund Command

Adding Funding Links to Your package.json

Get Real-Time GitHub Stars Notifications in Discord

Step 1: Create a Discord Webhook

Step 2: Create a GitHub Repository

Step 3: Create a Secret Variable in GitHub

Step 4: Create a GitHub Actions Workflow

The Algorithm

Using the GitHub API

The Actual Workflow

Step 5: Run the Workflow

Bluesky Starter Pack About Open Source

What’s in a Bluesky Starter Pack?

The Open Source Bluesky Starter Pack

Get Involved!

Who Is the Ghost User on GitHub?

The Role of the Ghost User

When Does the Ghost User Appear?

contrib.rocks: Generate an Image of GitHub Repositories Top Contributors

How to Use

Rendering

Repobeats: GitHub README analytics

Installation

Rendering

GitHub Marketplace: Social Preview for Your GitHub Actions

What Can We Do About It?

How To Check If It Works?

Find This Template On Figma

Display Your Sponsors in Your GitHub READMEs

Prerequisites

Create Your Repository

From the Starter Template

From a New Repository

Configure Your Repository

Change Default Permissions of GITHUB_TOKEN

Set up the environment variable

Configure the GitHub Action

Check Your Generated Images

(Optional) Generate The Images Locally

Use the Generated Images in Your READMEs

Final Result

Can I Take This Issue?

So Can I Take It or Not?

Why Do Some Maintainers Assign Issues?

Efficiency

Accountability and Responsibility

Encouraging Contributions

Better Resource Management

Avoiding Confusion

Why Do Some Maintainers Not Assign Issues?

Limited Resources

Large Communities

Collaborative Approach

Avoiding Favoritism

Trust Community

Lack of Familiarity

`npm fund` Command

Adding Funding Links to Your `package.json`