LibreSign / LibreSign/libresign

Ask first-time contributors for feedback after their first merged pull request

Open
#8,292 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

github_actions good first issue
Dominant language
PHP
Stars
818
Forks
146
Avg merge
11h 31m
Merged PRs (30d)
326

Description

LibreSign has been receiving useful contributions from new contributors.

A contributor's first merged pull request is an important moment. Their work is now part of LibreSign, and we want this experience to make them feel welcome and interested in contributing again.

This is a good time to:

  • thank them for their contribution;
  • make them feel part of the LibreSign community;
  • invite them to stay involved;
  • optionally ask for feedback about their contribution experience.

We should automatically leave a short and friendly message after a contributor gets their first pull request merged.

The feedback request must be optional and should not make the contributor feel that they need to complete a survey after contributing.

The message should:

  • congratulate them on their first accepted contribution;
  • thank them for sharing their time and knowledge;
  • make it clear that they are welcome to contribute again;
  • link to the LibreSign contributor survey;
  • invite them to join the LibreSign community.

Suggested implementation

Use zephyrproject-rtos/action-first-interaction.

This Action supports pr-merged-message and detects the first pull request from an author that was actually merged.

This is important because a contributor may have opened an earlier pull request that was closed without being accepted.

For example:

First pull request: closed without merge
Later pull request: merged

The message should be posted after the later pull request is merged, because it is the contributor's first successful contribution.

The Zephyr project created this behavior for first merged contributions:

StudioCMS also uses the same Action to welcome contributors after their first merged pull request:

https://github.com/withstudiocms/studiocms.dev/blob/main/.github/workflows/ci-first-contributor.yml

Pin the Action to a full commit SHA, following the current LibreSign GitHub Actions pattern.

At the time this issue was created, Zephyr uses:

58853996b1ac504b8e0f6964301f369d2bb22e5c # v1.1.1+zephyr.6

Check the current recommended version before opening the pull request.

Workflow

Add a small workflow such as:

.github/workflows/contributor-feedback.yml

Use:

on:
  pull_request_target:
    types: [closed]

The job should continue only when:

  • the pull request was merged;
  • the pull request author is not a bot.

For example:

if: >-
  github.event.pull_request.merged == true &&
  github.event.pull_request.user.type != 'Bot'

The workflow must:

  • use zephyrproject-rtos/action-first-interaction;
  • configure only pr-merged-message;
  • not use actions/checkout;
  • not execute code or files from the pull request;
  • not download pull request artifacts;
  • use GitHub configuration variables instead of hardcoding external URLs.

Permissions

Use explicit and minimal permissions.

The workflow needs to:

  • read pull request metadata;
  • search previous pull requests;
  • create a comment on the merged pull request.

Start from:

permissions: {}

jobs:
  first-merged-contribution:
    permissions:
      contents: read
      pull-requests: read
      issues: write

Do not add more permissions unless they are required.

Configuration

Use GitHub configuration variables:

CONTRIBUTOR_SURVEY_URL
COMMUNITY_URL

Do not hardcode the survey or community URLs in the workflow.

The survey URL will be created and provided by the LibreCode team.

Contributor survey

Creating or configuring the survey is not part of this issue.

The LibreCode team will create the survey in LimeSurvey and provide a working URL.

The survey should help us learn from contributors without making the first contribution experience feel like a long questionnaire.

It should help us understand:

  • how contributors discover LibreSign;
  • why they decide to contribute;
  • which parts of the contribution process are difficult;
  • how they experience the review process;
  • whether they would like to contribute again;
  • what kind of contributions they may be interested in;
  • whether LibreSign is used personally or by their organization.

The survey should be short and should normally take only a few minutes to complete.

It should not require the contributor to answer every question.

Questions about professional or organizational use should be optional and should only appear when relevant.

Responses should be anonymous by default.

The GitHub workflow must not automatically send:

  • GitHub username;
  • email;
  • pull request number;
  • other personal information.

The LimeSurvey configuration will support these context parameters:

source
repository

For this workflow:

source=github-first-merged-pr

The repository value should come from the GitHub event instead of being hardcoded.

For example:

repository=${{ github.event.repository.name }}

The final survey link should use the configured base URL and add only these controlled context values.

Do not add contributor identity or other GitHub text or data to the query string.

Suggested message

The message should first thank the contributor and welcome them to the community.

The survey should come after that.

A message similar to this would be good:

Hi @username! 🎉

Congratulations on your first contribution to LibreSign!

Your work is now part of the project. Thank you for sharing your time and knowledge with our community.

If you have a few minutes, we would be happy to hear about your experience. Your feedback helps us make LibreSign easier and more welcoming for future contributors:

[Contributor survey]

The survey is optional, and you are always welcome to keep contributing, ask questions, or join our community:

[Community link]

Thank you for helping LibreSign grow. We hope to see you again!

Keep the final message short.

Do not turn the post-merge comment into a contribution guide or onboarding document.

The contribution has already been accepted. The goal of this message is to thank the contributor, make them feel welcome, listen to their feedback and encourage them to contribute again.

Survey participation must not be required for any community benefit, recognition or future participation.

The final implementation should use the configured survey and community URLs.

Contribution guide

Add a small contributor feedback section to CONTRIBUTING.md using the same survey.

This allows us to receive feedback not only from contributors who successfully merged a pull request, but also from people who tried to contribute and stopped before their work was accepted.

A section similar to this is enough:

## Contributor feedback

Have you contributed or tried to contribute to LibreSign?

We would like to hear about your experience. Your feedback helps us improve our documentation, development setup, issue descriptions and review process.

[Contributor experience survey]

For the contribution guide link, use:

source=contributing-guide
repository=libresign

Repository scope

This first implementation is limited to the LibreSign/libresign repository.

zephyrproject-rtos/action-first-interaction detects the first merged pull request inside the current repository.

This means the same contributor could be treated as a first-time contributor again if this workflow is copied to another LibreSign repository without changes.

For example, a contributor could have:

first merge in LibreSign/libresign
first merge in LibreSign/pdf-elements
first merge in LibreSign/signer-php

With the current Action, each repository is checked separately.

Do not copy this workflow to other LibreSign repositories without reviewing this behavior first.

Before using the same workflow in more LibreSign repositories, we should check the contributor's first merge across all LibreSign repositories so the same person does not receive the welcome survey more than once.

This organization-wide check is outside the scope of this issue.

Security

This workflow uses pull_request_target.

Keep it very small and never execute untrusted pull request content.

In particular:

  • do not use actions/checkout;
  • do not run scripts from the pull request;
  • do not load configuration from the pull request;
  • do not download pull request artifacts;
  • do not expose secrets;
  • do not increase GitHub token permissions without a clear reason.

The workflow should only use GitHub event metadata, the GitHub API and the configured message.

References

Main implementation references:

Contributor feedback references:

The Zephyr workflow should be the main technical reference for the GitHub Action integration.

Done when

  • A contributor-feedback.yml workflow is added.
  • It runs on pull_request_target when pull requests are closed.
  • The job continues only when the pull request was merged.
  • Bots do not receive the message.
  • The message is posted only after the author's first successfully merged pull request in LibreSign/libresign.
  • An earlier pull request that was closed without merge does not stop the first merged contribution from receiving the message.
  • zephyrproject-rtos/action-first-interaction is pinned to a full commit SHA.
  • Only pr-merged-message is configured.
  • CONTRIBUTOR_SURVEY_URL is used for the survey URL.
  • COMMUNITY_URL is used for the community URL.
  • The survey receives source=github-first-merged-pr.
  • The repository survey parameter comes from the GitHub repository context.
  • No contributor identity is automatically sent to the survey.
  • The survey is clearly presented as optional.
  • The message thanks and welcomes the contributor before asking for feedback.
  • The message does not make any community benefit or recognition depend on completing the survey.
  • The survey is short enough to complete in a few minutes.
  • Questions about organizational use, support, sponsorship or partnership are optional.
  • No pull request code or artifact is checked out or executed.
  • GitHub token permissions are explicitly defined and kept to the minimum required.
  • CONTRIBUTING.md also links to the contributor survey with source=contributing-guide.
  • The workflow is tested with the working survey URL provided by the LibreCode team.
  • Existing repository checks continue to pass.

Out of scope

Do not:

  • create or configure the LimeSurvey survey;
  • configure Telegram notifications;
  • collect contributor identity automatically;
  • install a GitHub App;
  • implement custom first-contribution detection;
  • send this message after every merged pull request;
  • add a first-PR-opened onboarding message;
  • copy the same repository-scoped workflow to other LibreSign repositories;
  • implement the first-contribution check across all LibreSign repositories;
  • make survey participation required for any community benefit or recognition.

The LimeSurvey setup and notifications are handled separately by the LibreCode team.

A check across all LibreSign repositories can be evaluated separately before this workflow is reused in other repositories.

Good first issue

You do not need to understand the LibreSign PHP or Vue codebase to work on this issue.

The main work is:

  • one small GitHub Actions workflow;
  • configuring an existing Action;
  • adding a small contributor feedback section to CONTRIBUTING.md.

Please use the Zephyr workflow as the main reference and keep the implementation small and easy to review.

Do not add custom JavaScript or custom first-contribution detection unless there is a clear limitation in the referenced Action.

If something is not clear, ask in this issue before making the solution more complex.

Additional context
  • If you have questions, feel free to ask in this issue.
  • Give a ⭐️ star to this repository if you find LibreSign useful and would like to support the project.
  • You can also join our community: https://t.me/LibreSign

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the Zephyr workflow reference, then add .github/workflows/contributor-feedback.yml and update CONTRIBUTING.md. Check the pull_request_target conditions, action SHA pin, minimal permissions, configuration variables, and controlled survey parameters without checking out or executing pull request code. Done means the workflow and guide link meet every listed checklist item and existing repository checks pass.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions
Domain
ci-cd, documentation, security
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.