I remember to suggest a PR and the close response easily drive to correct place.
I know bugzilla and git.gnome.org by that time but guess that getting such response and don't look at it as it seems automatic is the real problem.
Anyway a README.md is available in our projects and is the default for github (and people used to github). Maybe a simple automatic rebase on master po f a README.md (and if you want a mirror-master branch as tip on github) can solve this
Hey,
As expected the GitHub mirror might be costing us some contributions
rather than attracting more:
- none of the projects repositories mention that the mirrors are
mirrors
- the READMEs don't mention that they're mirrors either, or point to
the upstream code, Bugzilla or code contributions
- none of the project pages on the Wiki mention that the GitHub repos
are mirrors
- the PR getting closed means that the contribution won't even be
looked at, after the person's figured out how to try and contribute to
the repository
>From a discussion with a colleague who tried to upstream a fix:
> I could not find instructions how to submit a patch, but the Github
> repository had pull requests enabled, so I submitted a fix there:
>
> Then [the automatic closure] happened:
> [...]
>
> At this point, I moved on to more productive things.
We really need a way to disable PRs, or disable the mirror.
At the *very least*, and that would need to happen yesterday, we need a
PR template mentioning that PRs will be closed, and the repository
descriptions mentioning that the repositories are mirrors.
Cheers
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list