devrel
devrel copied to clipboard
Improve `CONTRIBUTING.MD` to explain how we assign issues
Raised by @curquiza, to be discussed with her before starting working on it.
We don't want issues to remain open because their assignees do not work on them.
Currently, during the hacktoberfest and for the moment, here is what we answer to people about assignation: https://github.com/meilisearch/meilisearch-ruby/issues/236#issuecomment-944922752
We are looking for a sustainable solution (post Hacktoberfest)
Also, the docs team wants to assign issues before anyone starts working on them. This may add some friction tough. Let's discuss all options once Hacktoberfest is over.
@curquiza @dichotommy now that Hacktoberfest has ended, what are your insights on handling contributions (assigning issues)?
On the integration and MeiliSearch sides, we had the same problem assigning people to the issues: they often ask to be assigned, but they never come back to submit a PR or to ask to be un-assigned. These "blocked" issues discouraged the real volunteer contributors to submit PRs. Since we removed the assignations we had way more contributions.
I would use the assignation only
- for the Meili people
- and in rare cases, for some really trustable contributors. It happened sometimes in milli and meilisearch-sdk
Then I suggest to explain that we don't want to assign issues. If contributors want to be assigned an issue, we can tell them it's not something we do. wdyt @curquiza ?
Also @dichotommy this can be different for the doc repo. Let us know! thanks
If contributors want to be assigned an issue, we can tell them it's not something we do. wdyt @curquiza ?
I would also add a sentence about this issue policy in the contributing as well. SOrry if it's what you plan, I was not sure
We're currently discussing improving CONTRIBUTING.md
, sorry if this gets confusing with the many issues opened at the same time about community health files :)
Hey, sorry for the late response.
Within the docs team, we use assignments quite a lot. We use it for issues, to indicate that someone is actively working on the issue, and for PRs, to show that someone is currently reviewing or updating the PR. The latter is particularly important, because we do feedback in "rounds" and want to avoid the case where a PR is updated while someone is in the middle of reviewing it, invalidating their suggestions.
It's rare for us to get contributors working on open issues (most contributions that we receive are fixing typos or broken links 😓), so it's equally rare to assign an issue to an external contributor. I think we would be happy to follow a general rule of "no assigning issues to contributors" if that's what works best for other MeiliSearch repos.
Hi @dichotommy thanks for your answer. I will add then that we do not assign issues to external contributors!
I am sorry I totally forgot what's this about, does it impact anything else besides the templates repo?
I guess all repos that expect contributions
Ok. Should we make PRs to the concerned repos or ask their maintainers to make the modifications?
We could use @curquiza's tool to update many repos at once
Keep in mind my tool cannot be "dynamic" regarding the name of the repo. For example, the change @ferdi05 did in this PR involves you changing the repo URL depending on the repo. I need to upgrade my tool for this but currently is only possible to update the CONTRIBUTING manually if your changes depend on the repo name/URL.
EDIT: I forgot the link of the Ferdinand's PR -> https://github.com/meilisearch/meilisearch/pull/1908/files
written in Ruby, could this be a project for @CaroFG 👀 ?
Completely! 🚀 ❤️ I'm sorry in advance, there is no test to verify the work at the end 😬 (not proud of this, but I never had the time)