Howdy folks,
I was looking at our repo on Github, and frankly, I like it. But, I know for some employers they're rating potential employees on their Github profiles (I don't agree with this, but it happens) and so not having the commits in Github reduces the exposure for that work. This probably effects our "interns" from Google SoC and Outreachy the most. For reference: https://github.com/inkscape/inkscape The problem we've had in the past is that when we had the repo on Github, people would fork it and create Pull Requests that no one would see or triage. Which would frustrate folks (understandably) and look poor on the project. The idea that I had is that we take the Inkscape repo, and we make a branch "github" that has the same README and graphic that is currently up on Github. We push the full Inkscape repo, but then set the default visible branch to the "github" branch. So anyone going to the repository sees exactly the same thing. Github doesn't seem to have a mechanism for disabling PRs, or forks. So we're relying on people actually reading the text. But I was curious what folks thought about the idea. Ted
Hi Ted,
Looking after our students and their potential for jobs is a really good thing to do. Thank you for looking into the problem ted.
I *think* we're a lot more entrentched with GitLab, and it's stature is such that I don't percieve a direct threat to our team workflows by having a github mirror.
Although I would like the following things:
* An automatic script to answer posted issues pointing them to gitlab and closing the issue. * An automatic script to answer any pull request, pointing them to gitlab and closing the pull request.
Aside: Somewhere I'd like a report from both GitLab and if so, GitHub, about forks with changes less than half a year old. Sometimes people make changes and never submit them, thinking them not good enough and it can be a good source of changes and potential contributors.
But, this should probably go to the developer meeting in two days too: https://inkscape.org/cals/event/1/
Best Regards, Martin Owens
On Wed, 2022-06-08 at 22:48 -0500, Ted Gould wrote:
Howdy folks,
I was looking at our repo on Github, and frankly, I like it. But, I know for some employers they're rating potential employees on their Github profiles (I don't agree with this, but it happens) and so not having the commits in Github reduces the exposure for that work. This probably effects our "interns" from Google SoC and Outreachy the most.
For reference: https://github.com/inkscape/inkscape The problem we've had in the past is that when we had the repo on Github, people would fork it and create Pull Requests that no one would see or triage. Which would frustrate folks (understandably) and look poor on the project.
The idea that I had is that we take the Inkscape repo, and we make a branch "github" that has the same README and graphic that is currently up on Github. We push the full Inkscape repo, but then set the default visible branch to the "github" branch. So anyone going to the repository sees exactly the same thing.
Github doesn't seem to have a mechanism for disabling PRs, or forks. So we're relying on people actually reading the text. But I was curious what folks thought about the idea.
Ted _______________________________________________ Inkscape Devel mailing list -- inkscape-devel@lists.inkscape.org To unsubscribe send an email to inkscape-devel-leave@lists.inkscape.org
Hi,
I’d also be interested to utilize GitHub a bit more, I’d like to run CI there as well. Not to replace what we have, but just for fun and to increase „broad appeal“. Providing more ways that people can use and build our code can’t be bad, can it?
There are also enough solutions available to pick from to auto-close issues and pull requests with a comment „please go to GitLab“ or Similar, so I don’t think we’ll have a problem on that front.
As first step I’d like to become a member in the organization (same handle as on GitLab) :)
René
Am 09.06.2022 um 06:27 schrieb Martin Owens doctormo@geek-2.com:
Hi Ted,
Looking after our students and their potential for jobs is a really good thing to do. Thank you for looking into the problem ted.
I *think* we're a lot more entrentched with GitLab, and it's stature is such that I don't percieve a direct threat to our team workflows by having a github mirror.
Although I would like the following things:
- An automatic script to answer posted issues pointing them to gitlab
and closing the issue.
- An automatic script to answer any pull request, pointing them to
gitlab and closing the pull request.
Aside: Somewhere I'd like a report from both GitLab and if so, GitHub, about forks with changes less than half a year old. Sometimes people make changes and never submit them, thinking them not good enough and it can be a good source of changes and potential contributors.
But, this should probably go to the developer meeting in two days too: https://inkscape.org/cals/event/1/
Best Regards, Martin Owens
On Wed, 2022-06-08 at 22:48 -0500, Ted Gould wrote:
Howdy folks,
I was looking at our repo on Github, and frankly, I like it. But, I know for some employers they're rating potential employees on their Github profiles (I don't agree with this, but it happens) and so not having the commits in Github reduces the exposure for that work. This probably effects our "interns" from Google SoC and Outreachy the most.
For reference: https://github.com/inkscape/inkscape The problem we've had in the past is that when we had the repo on Github, people would fork it and create Pull Requests that no one would see or triage. Which would frustrate folks (understandably) and look poor on the project.
The idea that I had is that we take the Inkscape repo, and we make a branch "github" that has the same README and graphic that is currently up on Github. We push the full Inkscape repo, but then set the default visible branch to the "github" branch. So anyone going to the repository sees exactly the same thing.
Github doesn't seem to have a mechanism for disabling PRs, or forks. So we're relying on people actually reading the text. But I was curious what folks thought about the idea.
Ted _______________________________________________ Inkscape Devel mailing list -- inkscape-devel@lists.inkscape.org To unsubscribe send an email to inkscape-devel-leave@lists.inkscape.org
Inkscape Devel mailing list -- inkscape-devel@lists.inkscape.org To unsubscribe send an email to inkscape-devel-leave@lists.inkscape.org
Hi,
Although I would like the following things:
- An automatic script to answer posted issues pointing them to gitlab
and closing the issue.
- An automatic script to answer any pull request, pointing them to
gitlab and closing the pull request.
Many projects on GitHub have templates[0] for new issues and pull request which guide the users, provide questions etc.
Ours could simply be something like this:
"This repository is only a mirror of our GitLab project, issues and pull-requests will be automatically closed. Please report your issue here:
<link>"
[0] https://docs.github.com/en/communities/using-templates-to-encourage-useful-i...
Best Regards, Alexander
On 6/9/22 05:48, Ted Gould wrote:
The idea that I had is that we take the Inkscape repo, and we make a branch "github" that has the same README and graphic that is currently up on Github. We push the full Inkscape repo, but then set the default visible branch to the "github" branch. So anyone going to the repository sees exactly the same thing.
Seems like a good solution :)
K, it seems like there is stuff we need to setup, but people are generally happy with the idea of trying it out. I'll try to figure out the details in the next bit (baseball tournament this weekend, see how far the kid's team goes to how much time I have 😉)
Ted On Jun 8 2022, at 10:48 pm, Ted Gould ted@gould.cx wrote:
Howdy folks,
I was looking at our repo on Github, and frankly, I like it. But, I know for some employers they're rating potential employees on their Github profiles (I don't agree with this, but it happens) and so not having the commits in Github reduces the exposure for that work. This probably effects our "interns" from Google SoC and Outreachy the most. For reference: https://github.com/inkscape/inkscape The problem we've had in the past is that when we had the repo on Github, people would fork it and create Pull Requests that no one would see or triage. Which would frustrate folks (understandably) and look poor on the project.
The idea that I had is that we take the Inkscape repo, and we make a branch "github" that has the same README and graphic that is currently up on Github. We push the full Inkscape repo, but then set the default visible branch to the "github" branch. So anyone going to the repository sees exactly the same thing. Github doesn't seem to have a mechanism for disabling PRs, or forks. So we're relying on people actually reading the text. But I was curious what folks thought about the idea. Ted
Ted,
Thank you for being open to these ideas and encouraging ways for coding environments appealing to contributors to work together.
I would be wary of allowing any elements of the project to begin finding new or additional platforms to call home - maintaining the process in one place should be a priority over allowing additional forks to be scattered around various development environments; even with callbacks to help close issues, refer them to existing groups, etc.
Personally, I would encourage any targeted development or forks performed elsewhere to be submitted into the GitLab repository maintained by the Inkscape project, by the author(s) of such work, even if can or does exist elsewhere as a matter of preference.
Best,
Nathan
Sent from my iPhone
On Jun 10, 2022, at 8:41 AM, Ted Gould ted@gould.cx wrote:
K, it seems like there is stuff we need to setup, but people are generally happy with the idea of trying it out. I'll try to figure out the details in the next bit (baseball tournament this weekend, see how far the kid's team goes to how much time I have 😉)
Ted
On Jun 8 2022, at 10:48 pm, Ted Gould ted@gould.cx wrote: Howdy folks,
I was looking at our repo on Github, and frankly, I like it. But, I know for some employers they're rating potential employees on their Github profiles (I don't agree with this, but it happens) and so not having the commits in Github reduces the exposure for that work. This probably effects our "interns" from Google SoC and Outreachy the most.
For reference: https://github.com/inkscape/inkscape The problem we've had in the past is that when we had the repo on Github, people would fork it and create Pull Requests that no one would see or triage. Which would frustrate folks (understandably) and look poor on the project.
The idea that I had is that we take the Inkscape repo, and we make a branch "github" that has the same README and graphic that is currently up on Github. We push the full Inkscape repo, but then set the default visible branch to the "github" branch. So anyone going to the repository sees exactly the same thing.
Github doesn't seem to have a mechanism for disabling PRs, or forks. So we're relying on people actually reading the text. But I was curious what folks thought about the idea.
Ted _______________________________________________ Inkscape Devel mailing list -- inkscape-devel@lists.inkscape.org To unsubscribe send an email to inkscape-devel-leave@lists.inkscape.org
Hi all,
please also consider what SFC is currently suggesting in their GiveUpGitHub campaign when making that decision.
https://mastodon.technology/@conservancy/108566696125594772
Maren
https://mastodon.technology/@conservancy/108566696125594772
Am 12.06.22 um 10:50 schrieb Nathan P. Johansen:
Ted,
Thank you for being open to these ideas and encouraging ways for coding environments appealing to contributors to work together.
I would be wary of allowing any elements of the project to begin finding new or additional platforms to call home - maintaining the process in one place should be a priority over allowing additional forks to be scattered around various development environments; even with callbacks to help close issues, refer them to existing groups, etc.
Personally, I would encourage any targeted development or forks performed elsewhere to be submitted into the GitLab repository maintained by the Inkscape project, by the author(s) of such work, even if can or does exist elsewhere as a matter of preference.
Best,
Nathan
Sent from my iPhone
On Jun 10, 2022, at 8:41 AM, Ted Gould ted@gould.cx wrote:
K, it seems like there is stuff we need to setup, but people are generally happy with the idea of trying it out. I'll try to figure out the details in the next bit (baseball tournament this weekend, see how far the kid's team goes to how much time I have 😉)
Ted
On Jun 8 2022, at 10:48 pm, Ted Gould ted@gould.cx wrote:
Howdy folks, I was looking at our repo on Github, and frankly, I like it. But, I know for some employers they're rating potential employees on their Github profiles (I don't agree with this, but it happens) and so not having the commits in Github reduces the exposure for that work. This probably effects our "interns" from Google SoC and Outreachy the most. For reference: https://github.com/inkscape/inkscape <https://github.com/inkscape/inkscape> The problem we've had in the past is that when we had the repo on Github, people would fork it and create Pull Requests that no one would see or triage. Which would frustrate folks (understandably) and look poor on the project. The idea that I had is that we take the Inkscape repo, and we make a branch "github" that has the same README and graphic that is currently up on Github. We push the full Inkscape repo, but then set the default visible branch to the "github" branch. So anyone going to the repository sees exactly the same thing. Github doesn't seem to have a mechanism for disabling PRs, or forks. So we're relying on people actually reading the text. But I was curious what folks thought about the idea. Ted
Inkscape Devel mailing list -- inkscape-devel@lists.inkscape.org To unsubscribe send an email to inkscape-devel-leave@lists.inkscape.org
Inkscape Devel mailing list -- inkscape-devel@lists.inkscape.org To unsubscribe send an email to inkscape-devel-leave@lists.inkscape.org
participants (7)
-
Alexander Brock -
Marc Jeanmougin -
Maren Hachmann -
Martin Owens -
Nathan P. Johansen -
René de Hesselle -
Ted Gould