There's a setting "Allow users to request access" on our Inkscape main group (https://gitlab.com/inkscape). I'd like to switch it to 'off'. Are there any objections if I did this?
This setting adds a button to our website for logged in users to push to send an email to our admins asking for membership to the inkscape main group. The effect of this gives them commit access on the inkscape repo (and I suspect maybe other git repos in subgroups; I'm not sure how the permissions propagate.)
This was useful initially when everyone was needing gitlab access, but I think all the existing committers that want it have it. These days the requests we're getting are mostly from people with no registered activity related to Inkscape; we've been getting a handful of these invalid requests each month. Maybe they're clicking it on accident, or thinking that it's an affiliation mark, and not realizing that it gives full commit rights if granted.
Turning it off simply removes the button, it wouldn't mean any change to our existing policies regarding earning of commit rights - applicants still need to get two patches reviewed, accepted, and landed and then contact one of the administrators to request access. (If we want to make this simpler later on, maybe one day we can rig up a form where they can enter the SHAs of their two patches.)
Bryce
No objection from me, sounds nice (I did not know we could remove the button^^); what I tried to do at some point was to give "Guest" role to those users (which does not grant any right)
On Sat, Jan 13, 2018 at 09:32:03AM +0100, Marc Jeanmougin wrote:
No objection from me, sounds nice (I did not know we could remove the button^^); what I tried to do at some point was to give "Guest" role to those users (which does not grant any right)
I also wondered about establishing an Inkscape Users subgroup that people could voluntarily add themselves to. (This might be worth doing regardless, particularly if we have some utility for it beyond just affiliation.)
Bryce
On 01/13/2018 06:28 AM, Bryce Harrington wrote:
There's a setting "Allow users to request access" on our Inkscape main group (https://gitlab.com/inkscape). I'd like to switch it to 'off'. Are there any objections if I did this?
This setting adds a button to our website for logged in users to push to send an email to our admins asking for membership to the inkscape main group. The effect of this gives them commit access on the inkscape repo (and I suspect maybe other git repos in subgroups; I'm not sure how the permissions propagate.)
This was useful initially when everyone was needing gitlab access, but I think all the existing committers that want it have it. These days the requests we're getting are mostly from people with no registered activity related to Inkscape; we've been getting a handful of these invalid requests each month. Maybe they're clicking it on accident, or thinking that it's an affiliation mark, and not realizing that it gives full commit rights if granted.
Turning it off simply removes the button, it wouldn't mean any change to our existing policies regarding earning of commit rights - applicants still need to get two patches reviewed, accepted, and landed and then contact one of the administrators to request access. (If we want to make this simpler later on, maybe one day we can rig up a form where they can enter the SHAs of their two patches.)
Bryce
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I've proceeded ahead and made this config change to gitlab. Let me know if anyone spots any issues with this change.
Bryce
On Sat, Jan 13, 2018 at 09:10:59AM -0800, Bryce Harrington wrote:
On Sat, Jan 13, 2018 at 09:32:03AM +0100, Marc Jeanmougin wrote:
No objection from me, sounds nice (I did not know we could remove the button^^); what I tried to do at some point was to give "Guest" role to those users (which does not grant any right)
I also wondered about establishing an Inkscape Users subgroup that people could voluntarily add themselves to. (This might be worth doing regardless, particularly if we have some utility for it beyond just affiliation.)
Bryce
On 01/13/2018 06:28 AM, Bryce Harrington wrote:
There's a setting "Allow users to request access" on our Inkscape main group (https://gitlab.com/inkscape). I'd like to switch it to 'off'. Are there any objections if I did this?
This setting adds a button to our website for logged in users to push to send an email to our admins asking for membership to the inkscape main group. The effect of this gives them commit access on the inkscape repo (and I suspect maybe other git repos in subgroups; I'm not sure how the permissions propagate.)
This was useful initially when everyone was needing gitlab access, but I think all the existing committers that want it have it. These days the requests we're getting are mostly from people with no registered activity related to Inkscape; we've been getting a handful of these invalid requests each month. Maybe they're clicking it on accident, or thinking that it's an affiliation mark, and not realizing that it gives full commit rights if granted.
Turning it off simply removes the button, it wouldn't mean any change to our existing policies regarding earning of commit rights - applicants still need to get two patches reviewed, accepted, and landed and then contact one of the administrators to request access. (If we want to make this simpler later on, maybe one day we can rig up a form where they can enter the SHAs of their two patches.)
Bryce
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Could someone add a link to the info about how to join/participate to the README?
After following a detour via 'CONTRIBUTING', which would be a symlink locally, but just had a path printed inside on gitlab, I found a description here: https://gitlab.com/inkscape/inkscape/blob/master/doc/HACKING.txt
I think that file also needs an update, telling users *how* to 'request access' now that the option via button is closed.
(what would have been the issue with just declining any non-contributor join requests? Not being able to add an explanatory note? Perhaps make this a gitlab feature request?)
Maren
Am 14.01.2018 um 03:29 schrieb Bryce Harrington:
I've proceeded ahead and made this config change to gitlab. Let me know if anyone spots any issues with this change.
Bryce
On Sat, Jan 13, 2018 at 09:10:59AM -0800, Bryce Harrington wrote:
On Sat, Jan 13, 2018 at 09:32:03AM +0100, Marc Jeanmougin wrote:
No objection from me, sounds nice (I did not know we could remove the button^^); what I tried to do at some point was to give "Guest" role to those users (which does not grant any right)
I also wondered about establishing an Inkscape Users subgroup that people could voluntarily add themselves to. (This might be worth doing regardless, particularly if we have some utility for it beyond just affiliation.)
Bryce
On 01/13/2018 06:28 AM, Bryce Harrington wrote:
There's a setting "Allow users to request access" on our Inkscape main group (https://gitlab.com/inkscape). I'd like to switch it to 'off'. Are there any objections if I did this?
This setting adds a button to our website for logged in users to push to send an email to our admins asking for membership to the inkscape main group. The effect of this gives them commit access on the inkscape repo (and I suspect maybe other git repos in subgroups; I'm not sure how the permissions propagate.)
This was useful initially when everyone was needing gitlab access, but I think all the existing committers that want it have it. These days the requests we're getting are mostly from people with no registered activity related to Inkscape; we've been getting a handful of these invalid requests each month. Maybe they're clicking it on accident, or thinking that it's an affiliation mark, and not realizing that it gives full commit rights if granted.
Turning it off simply removes the button, it wouldn't mean any change to our existing policies regarding earning of commit rights - applicants still need to get two patches reviewed, accepted, and landed and then contact one of the administrators to request access. (If we want to make this simpler later on, maybe one day we can rig up a form where they can enter the SHAs of their two patches.)
Bryce
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, Jan 14, 2018 at 04:39:17AM +0100, Maren Hachmann wrote:
Could someone add a link to the info about how to join/participate to the README?
After following a detour via 'CONTRIBUTING', which would be a symlink locally, but just had a path printed inside on gitlab, I found a description here: https://gitlab.com/inkscape/inkscape/blob/master/doc/HACKING.txt
I think that file also needs an update, telling users *how* to 'request access' now that the option via button is closed.
(what would have been the issue with just declining any non-contributor join requests? Not being able to add an explanatory note? Perhaps make this a gitlab feature request?)
Right, there is no explanation included in the requests. So there's not an easy way to tell if someone has contributed patches, whether they've been accepted, or etc. I suspect no one getting these notices knows what to do with them, so they've been just piling up; I sometimes do some sleuthing around to see if the individual has done anything with Inkscape, but it's time consuming to chase down their contribution history from scratch. The only practical way that applying works is if the applicant has been working with a developer and that developer knows they're applying for access -- in which case the developer can just add them directly, no need for the applicant to also click the button.
We had a similar problem with Launchpad, although there it had a feedback form to send the applicant an email directing them as to what they'd need to do. Also, in LP it was a bit fewer clicks to identify what they did for Inkscape, although it was still ambiguous if they'd gone through the proper process.
You are right that this could use better documentation. The HACKING file is a good start.
In general, I think most people who need commit access will be hooking in enough with the project and the rest of the developers that someone will help them get it, without needing a lot of structure. (If they're not hooked in to that level, well might not be a good candidate for giving commit rights anyway...) So I think for now, just having people ask on the inkscape-devel@ list or IRC for commit access is going to be sufficient, basically similar to how we handle wiki access.
I don't know if it is worth bothering asking for our process as a gitlab feature request, as we may be kind of unique with this. In any case I suspect it's not that hard for us to implement some web UI ourselves to accomplish the same goal, if it really bothers us.
Blue sky, maybe someday we could have some sort of unified membership access request form, to request wiki access, commit access, travel sponsorship, et al. And a corresponding administrative side page to review/comment/approve applications. It would be nice if that app had a way to programmatically tell if the user had fulfilled whatever requirements are set for access (i.e. the 2-patch rule, length of time in the project, etc.) If anyone wishes to work on such a web form, I can share further ideas, but I think we can handle things manually for the time being.
Bryce
Maren
Am 14.01.2018 um 03:29 schrieb Bryce Harrington:
I've proceeded ahead and made this config change to gitlab. Let me know if anyone spots any issues with this change.
Bryce
On Sat, Jan 13, 2018 at 09:10:59AM -0800, Bryce Harrington wrote:
On Sat, Jan 13, 2018 at 09:32:03AM +0100, Marc Jeanmougin wrote:
No objection from me, sounds nice (I did not know we could remove the button^^); what I tried to do at some point was to give "Guest" role to those users (which does not grant any right)
I also wondered about establishing an Inkscape Users subgroup that people could voluntarily add themselves to. (This might be worth doing regardless, particularly if we have some utility for it beyond just affiliation.)
Bryce
On 01/13/2018 06:28 AM, Bryce Harrington wrote:
There's a setting "Allow users to request access" on our Inkscape main group (https://gitlab.com/inkscape). I'd like to switch it to 'off'. Are there any objections if I did this?
This setting adds a button to our website for logged in users to push to send an email to our admins asking for membership to the inkscape main group. The effect of this gives them commit access on the inkscape repo (and I suspect maybe other git repos in subgroups; I'm not sure how the permissions propagate.)
This was useful initially when everyone was needing gitlab access, but I think all the existing committers that want it have it. These days the requests we're getting are mostly from people with no registered activity related to Inkscape; we've been getting a handful of these invalid requests each month. Maybe they're clicking it on accident, or thinking that it's an affiliation mark, and not realizing that it gives full commit rights if granted.
Turning it off simply removes the button, it wouldn't mean any change to our existing policies regarding earning of commit rights - applicants still need to get two patches reviewed, accepted, and landed and then contact one of the administrators to request access. (If we want to make this simpler later on, maybe one day we can rig up a form where they can enter the SHAs of their two patches.)
Bryce
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Mmmh - to find out if someone has contributed twice, one can go to https://gitlab.com/inkscape/inkscape/graphs/master, scroll down to bottom to be sure the page has fully loaded, and then use Ctrl+F with their user name on gitlab - or do some "git log | grep <email address or user name>" magic on the command line. Maybe that wouldn't get all contributions, but well, there's a limit to what people can be expected to do for research, as you say.
The feature request I was talking about was about adding a reason when declining. Something like 'I'm not granting you access right now, because I cannot find your 2 required commits. Please contact us/me at .... if you know you fulfill our commit access criteria listed at ... (and introduce yourself on the mailing list)". Not about adding the option to write an 'application' - I looked at it from the outside, not from the side of the person who can grant access.
The thing about not being connected to the community is an issue that can't be solved with any of both mentioned features, though.
I worry that this change makes the project look 'closed' to outsiders (at least projects that do that give that impression to me), if there's nothing in the README, nor an up-to-date explanation anywhere how to become a project member. I think even people who have worked with a developer might not know how. Or do mentors routinely explain/offer this if not asked explicitly for info?
Btw. the 'Request access' button is still there at https://gitlab.com/inkscape/inkscape
(the Inkscape group is where it is disabled now)
Maren
Am 14.01.2018 um 05:22 schrieb Bryce Harrington:
On Sun, Jan 14, 2018 at 04:39:17AM +0100, Maren Hachmann wrote:
Could someone add a link to the info about how to join/participate to the README?
After following a detour via 'CONTRIBUTING', which would be a symlink locally, but just had a path printed inside on gitlab, I found a description here: https://gitlab.com/inkscape/inkscape/blob/master/doc/HACKING.txt
I think that file also needs an update, telling users *how* to 'request access' now that the option via button is closed.
(what would have been the issue with just declining any non-contributor join requests? Not being able to add an explanatory note? Perhaps make this a gitlab feature request?)
Right, there is no explanation included in the requests. So there's not an easy way to tell if someone has contributed patches, whether they've been accepted, or etc. I suspect no one getting these notices knows what to do with them, so they've been just piling up; I sometimes do some sleuthing around to see if the individual has done anything with Inkscape, but it's time consuming to chase down their contribution history from scratch. The only practical way that applying works is if the applicant has been working with a developer and that developer knows they're applying for access -- in which case the developer can just add them directly, no need for the applicant to also click the button.
We had a similar problem with Launchpad, although there it had a feedback form to send the applicant an email directing them as to what they'd need to do. Also, in LP it was a bit fewer clicks to identify what they did for Inkscape, although it was still ambiguous if they'd gone through the proper process.
You are right that this could use better documentation. The HACKING file is a good start.
In general, I think most people who need commit access will be hooking in enough with the project and the rest of the developers that someone will help them get it, without needing a lot of structure. (If they're not hooked in to that level, well might not be a good candidate for giving commit rights anyway...) So I think for now, just having people ask on the inkscape-devel@ list or IRC for commit access is going to be sufficient, basically similar to how we handle wiki access.
I don't know if it is worth bothering asking for our process as a gitlab feature request, as we may be kind of unique with this. In any case I suspect it's not that hard for us to implement some web UI ourselves to accomplish the same goal, if it really bothers us.
Blue sky, maybe someday we could have some sort of unified membership access request form, to request wiki access, commit access, travel sponsorship, et al. And a corresponding administrative side page to review/comment/approve applications. It would be nice if that app had a way to programmatically tell if the user had fulfilled whatever requirements are set for access (i.e. the 2-patch rule, length of time in the project, etc.) If anyone wishes to work on such a web form, I can share further ideas, but I think we can handle things manually for the time being.
Bryce
Maren
Am 14.01.2018 um 03:29 schrieb Bryce Harrington:
I've proceeded ahead and made this config change to gitlab. Let me know if anyone spots any issues with this change.
Bryce
On Sat, Jan 13, 2018 at 09:10:59AM -0800, Bryce Harrington wrote:
On Sat, Jan 13, 2018 at 09:32:03AM +0100, Marc Jeanmougin wrote:
No objection from me, sounds nice (I did not know we could remove the button^^); what I tried to do at some point was to give "Guest" role to those users (which does not grant any right)
I also wondered about establishing an Inkscape Users subgroup that people could voluntarily add themselves to. (This might be worth doing regardless, particularly if we have some utility for it beyond just affiliation.)
Bryce
On 01/13/2018 06:28 AM, Bryce Harrington wrote:
There's a setting "Allow users to request access" on our Inkscape main group (https://gitlab.com/inkscape). I'd like to switch it to 'off'. Are there any objections if I did this?
This setting adds a button to our website for logged in users to push to send an email to our admins asking for membership to the inkscape main group. The effect of this gives them commit access on the inkscape repo (and I suspect maybe other git repos in subgroups; I'm not sure how the permissions propagate.)
This was useful initially when everyone was needing gitlab access, but I think all the existing committers that want it have it. These days the requests we're getting are mostly from people with no registered activity related to Inkscape; we've been getting a handful of these invalid requests each month. Maybe they're clicking it on accident, or thinking that it's an affiliation mark, and not realizing that it gives full commit rights if granted.
Turning it off simply removes the button, it wouldn't mean any change to our existing policies regarding earning of commit rights - applicants still need to get two patches reviewed, accepted, and landed and then contact one of the administrators to request access. (If we want to make this simpler later on, maybe one day we can rig up a form where they can enter the SHAs of their two patches.)
Bryce
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, Jan 14, 2018 at 06:07:26AM +0100, Maren Hachmann wrote:
Mmmh - to find out if someone has contributed twice, one can go to https://gitlab.com/inkscape/inkscape/graphs/master, scroll down to bottom to be sure the page has fully loaded, and then use Ctrl+F with their user name on gitlab - or do some "git log | grep <email address or user name>" magic on the command line. Maybe that wouldn't get all contributions, but well, there's a limit to what people can be expected to do for research, as you say.
Yep, if we could get that procedure scripted and automated, that'd be the main piece of a better access request tool.
The feature request I was talking about was about adding a reason when declining. Something like 'I'm not granting you access right now, because I cannot find your 2 required commits. Please contact us/me at .... if you know you fulfill our commit access criteria listed at ... (and introduce yourself on the mailing list)". Not about adding the option to write an 'application' - I looked at it from the outside, not from the side of the person who can grant access.
Ah, yes a rationale field like was in Launchpad, not a bad idea to request. Again though, most of the requests we get are not legitimate so it increases admin work a lot for not much benefit; an application field filled in by the user would be more positively helpful.
The thing about not being connected to the community is an issue that can't be solved with any of both mentioned features, though.
I worry that this change makes the project look 'closed' to outsiders (at least projects that do that give that impression to me), if there's nothing in the README, nor an up-to-date explanation anywhere how to become a project member. I think even people who have worked with a developer might not know how. Or do mentors routinely explain/offer this if not asked explicitly for info?
I'm not that worried about that. Inkscape's actually fairly liberal with commit access so most open source developers needing commit access are used to needing to engage directly with the community.
That said, improving the docs to this effect would be nice, as I mentioned before. Feel free to add mention where you think it should be.
Some day I'd like to restructure our new devel intro materials a bit better, defining our development principles and so on, and if no one gets around to it before then I'll do another take at the commit access request directions.
Meanwhile, just keep an eye out for new folks that are actively contributing and might make good candidates for commit access and give them a personal invite. (This is probably a far friendlier and better way to bring in new devs than a button, anyway.)
Btw. the 'Request access' button is still there at https://gitlab.com/inkscape/inkscape
Thanks, I've fixed that. Looks like the top-level settings don't get inherited. We should probably move the core codebases into an Inkscape Devels subteam, and I think that may let us standardize the settings for the code repos. I'll have to think on this.
(the Inkscape group is where it is disabled now)
I've updated the projects to conform. One thing I'm uncertain about is from the description it says that this increases certain restrictions on anonymous users which may or may not be what we want. If access to anything seems to have gotten more restrictive in a bad way, let me know and I'll make adjustments.
Thanks again for reviewing this change and providing feedback. And like I mentioned, if anyone spots any serious issues with it going forward let me know and we can re-evaluate.
Bryce
Maren
Am 14.01.2018 um 05:22 schrieb Bryce Harrington:
On Sun, Jan 14, 2018 at 04:39:17AM +0100, Maren Hachmann wrote:
Could someone add a link to the info about how to join/participate to the README?
After following a detour via 'CONTRIBUTING', which would be a symlink locally, but just had a path printed inside on gitlab, I found a description here: https://gitlab.com/inkscape/inkscape/blob/master/doc/HACKING.txt
I think that file also needs an update, telling users *how* to 'request access' now that the option via button is closed.
(what would have been the issue with just declining any non-contributor join requests? Not being able to add an explanatory note? Perhaps make this a gitlab feature request?)
Right, there is no explanation included in the requests. So there's not an easy way to tell if someone has contributed patches, whether they've been accepted, or etc. I suspect no one getting these notices knows what to do with them, so they've been just piling up; I sometimes do some sleuthing around to see if the individual has done anything with Inkscape, but it's time consuming to chase down their contribution history from scratch. The only practical way that applying works is if the applicant has been working with a developer and that developer knows they're applying for access -- in which case the developer can just add them directly, no need for the applicant to also click the button.
We had a similar problem with Launchpad, although there it had a feedback form to send the applicant an email directing them as to what they'd need to do. Also, in LP it was a bit fewer clicks to identify what they did for Inkscape, although it was still ambiguous if they'd gone through the proper process.
You are right that this could use better documentation. The HACKING file is a good start.
In general, I think most people who need commit access will be hooking in enough with the project and the rest of the developers that someone will help them get it, without needing a lot of structure. (If they're not hooked in to that level, well might not be a good candidate for giving commit rights anyway...) So I think for now, just having people ask on the inkscape-devel@ list or IRC for commit access is going to be sufficient, basically similar to how we handle wiki access.
I don't know if it is worth bothering asking for our process as a gitlab feature request, as we may be kind of unique with this. In any case I suspect it's not that hard for us to implement some web UI ourselves to accomplish the same goal, if it really bothers us.
Blue sky, maybe someday we could have some sort of unified membership access request form, to request wiki access, commit access, travel sponsorship, et al. And a corresponding administrative side page to review/comment/approve applications. It would be nice if that app had a way to programmatically tell if the user had fulfilled whatever requirements are set for access (i.e. the 2-patch rule, length of time in the project, etc.) If anyone wishes to work on such a web form, I can share further ideas, but I think we can handle things manually for the time being.
Bryce
Maren
Am 14.01.2018 um 03:29 schrieb Bryce Harrington:
I've proceeded ahead and made this config change to gitlab. Let me know if anyone spots any issues with this change.
Bryce
On Sat, Jan 13, 2018 at 09:10:59AM -0800, Bryce Harrington wrote:
On Sat, Jan 13, 2018 at 09:32:03AM +0100, Marc Jeanmougin wrote:
No objection from me, sounds nice (I did not know we could remove the button^^); what I tried to do at some point was to give "Guest" role to those users (which does not grant any right)
I also wondered about establishing an Inkscape Users subgroup that people could voluntarily add themselves to. (This might be worth doing regardless, particularly if we have some utility for it beyond just affiliation.)
Bryce
On 01/13/2018 06:28 AM, Bryce Harrington wrote: > There's a setting "Allow users to request access" on our Inkscape main > group (https://gitlab.com/inkscape). I'd like to switch it to 'off'. > Are there any objections if I did this? > > This setting adds a button to our website for logged in users to push to > send an email to our admins asking for membership to the inkscape main > group. The effect of this gives them commit access on the inkscape repo > (and I suspect maybe other git repos in subgroups; I'm not sure how the > permissions propagate.) > > This was useful initially when everyone was needing gitlab access, but I > think all the existing committers that want it have it. These days the > requests we're getting are mostly from people with no registered > activity related to Inkscape; we've been getting a handful of these > invalid requests each month. Maybe they're clicking it on accident, or > thinking that it's an affiliation mark, and not realizing that it gives > full commit rights if granted. > > Turning it off simply removes the button, it wouldn't mean any change to > our existing policies regarding earning of commit rights - applicants > still need to get two patches reviewed, accepted, and landed and then > contact one of the administrators to request access. (If we want to > make this simpler later on, maybe one day we can rig up a form where > they can enter the SHAs of their two patches.) > > Bryce > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi, in git time maybe is better 2 patches substituted by 2 merge request ¿aproved?.
Any user can do a fork, start coding and submit a MR to the proyect. with or without access rights.
This is, I think, the git way to it, instead patches.
Also I couldent find the way to get in sync automaticaly my inkscape personal repo with inkscape one.
If this can be done by default, we can sugest leave in forks master branch clean and work with personal branches and MR.
This also reduce the number of branches in master (they realy not removed anyway you press remove it after MR merge.)
Cheers, J.
On Sat, 2018-01-13 at 22:49 -0800, Bryce Harrington wrote:
On Sun, Jan 14, 2018 at 06:07:26AM +0100, Maren Hachmann wrote:
Mmmh - to find out if someone has contributed twice, one can go to https://gitlab.com/inkscape/inkscape/graphs/master, scroll down to bottom to be sure the page has fully loaded, and then use Ctrl+F with their user name on gitlab - or do some "git log
grep <email address or user name>" magic on the command line. Maybe
that wouldn't get all contributions, but well, there's a limit to what people can be expected to do for research, as you say.
Yep, if we could get that procedure scripted and automated, that'd be the main piece of a better access request tool.
The feature request I was talking about was about adding a reason when declining. Something like 'I'm not granting you access right now, because I cannot find your 2 required commits. Please contact us/me at .... if you know you fulfill our commit access criteria listed at ... (and introduce yourself on the mailing list)". Not about adding the option to write an 'application' - I looked at it from the outside, not from the side of the person who can grant access.
Ah, yes a rationale field like was in Launchpad, not a bad idea to request. Again though, most of the requests we get are not legitimate so it increases admin work a lot for not much benefit; an application field filled in by the user would be more positively helpful.
The thing about not being connected to the community is an issue that can't be solved with any of both mentioned features, though.
I worry that this change makes the project look 'closed' to outsiders (at least projects that do that give that impression to me), if there's nothing in the README, nor an up-to-date explanation anywhere how to become a project member. I think even people who have worked with a developer might not know how. Or do mentors routinely explain/offer this if not asked explicitly for info?
I'm not that worried about that. Inkscape's actually fairly liberal with commit access so most open source developers needing commit access are used to needing to engage directly with the community.
That said, improving the docs to this effect would be nice, as I mentioned before. Feel free to add mention where you think it should be.
Some day I'd like to restructure our new devel intro materials a bit better, defining our development principles and so on, and if no one gets around to it before then I'll do another take at the commit access request directions.
Meanwhile, just keep an eye out for new folks that are actively contributing and might make good candidates for commit access and give them a personal invite. (This is probably a far friendlier and better way to bring in new devs than a button, anyway.)
Btw. the 'Request access' button is still there at https://gitlab.com/inkscape/inkscape
Thanks, I've fixed that. Looks like the top-level settings don't get inherited. We should probably move the core codebases into an Inkscape Devels subteam, and I think that may let us standardize the settings for the code repos. I'll have to think on this.
(the Inkscape group is where it is disabled now)
I've updated the projects to conform. One thing I'm uncertain about is from the description it says that this increases certain restrictions on anonymous users which may or may not be what we want. If access to anything seems to have gotten more restrictive in a bad way, let me know and I'll make adjustments.
Thanks again for reviewing this change and providing feedback. And like I mentioned, if anyone spots any serious issues with it going forward let me know and we can re-evaluate.
Bryce
Maren
Am 14.01.2018 um 05:22 schrieb Bryce Harrington:
On Sun, Jan 14, 2018 at 04:39:17AM +0100, Maren Hachmann wrote:
Could someone add a link to the info about how to join/participate to the README?
After following a detour via 'CONTRIBUTING', which would be a symlink locally, but just had a path printed inside on gitlab, I found a description here: https://gitlab.com/inkscape/inkscape/blob/master/doc/HACKING.tx t
I think that file also needs an update, telling users *how* to 'request access' now that the option via button is closed.
(what would have been the issue with just declining any non- contributor join requests? Not being able to add an explanatory note? Perhaps make this a gitlab feature request?)
Right, there is no explanation included in the requests. So there's not an easy way to tell if someone has contributed patches, whether they've been accepted, or etc. I suspect no one getting these notices knows what to do with them, so they've been just piling up; I sometimes do some sleuthing around to see if the individual has done anything with Inkscape, but it's time consuming to chase down their contribution history from scratch. The only practical way that applying works is if the applicant has been working with a developer and that developer knows they're applying for access -- in which case the developer can just add them directly, no need for the applicant to also click the button.
We had a similar problem with Launchpad, although there it had a feedback form to send the applicant an email directing them as to what they'd need to do. Also, in LP it was a bit fewer clicks to identify what they did for Inkscape, although it was still ambiguous if they'd gone through the proper process.
You are right that this could use better documentation. The HACKING file is a good start.
In general, I think most people who need commit access will be hooking in enough with the project and the rest of the developers that someone will help them get it, without needing a lot of structure. (If they're not hooked in to that level, well might not be a good candidate for giving commit rights anyway...) So I think for now, just having people ask on the inkscape-devel@ list or IRC for commit access is going to be sufficient, basically similar to how we handle wiki access.
I don't know if it is worth bothering asking for our process as a gitlab feature request, as we may be kind of unique with this. In any case I suspect it's not that hard for us to implement some web UI ourselves to accomplish the same goal, if it really bothers us.
Blue sky, maybe someday we could have some sort of unified membership access request form, to request wiki access, commit access, travel sponsorship, et al. And a corresponding administrative side page to review/comment/approve applications. It would be nice if that app had a way to programmatically tell if the user had fulfilled whatever requirements are set for access (i.e. the 2-patch rule, length of time in the project, etc.) If anyone wishes to work on such a web form, I can share further ideas, but I think we can handle things manually for the time being.
Bryce
Maren
Am 14.01.2018 um 03:29 schrieb Bryce Harrington:
I've proceeded ahead and made this config change to gitlab. Let me know if anyone spots any issues with this change.
Bryce
On Sat, Jan 13, 2018 at 09:10:59AM -0800, Bryce Harrington wrote:
On Sat, Jan 13, 2018 at 09:32:03AM +0100, Marc Jeanmougin wrote: > No objection from me, sounds nice (I did not know we > could remove the > button^^); what I tried to do at some point was to give > "Guest" role to > those users (which does not grant any right)
I also wondered about establishing an Inkscape Users subgroup that people could voluntarily add themselves to. (This might be worth doing regardless, particularly if we have some utility for it beyond just affiliation.)
Bryce
> On 01/13/2018 06:28 AM, Bryce Harrington wrote: > > There's a setting "Allow users to request access" on > > our Inkscape main > > group (https://gitlab.com/inkscape).%C2%A0%C2%A0I%27d like to > > switch it to 'off'. > > Are there any objections if I did this? > > > > This setting adds a button to our website for logged in > > users to push to > > send an email to our admins asking for membership to > > the inkscape main > > group. The effect of this gives them commit access on > > the inkscape repo > > (and I suspect maybe other git repos in subgroups; I'm > > not sure how the > > permissions propagate.) > > > > This was useful initially when everyone was needing > > gitlab access, but I > > think all the existing committers that want it have > > it. These days the > > requests we're getting are mostly from people with no > > registered > > activity related to Inkscape; we've been getting a > > handful of these > > invalid requests each month. Maybe they're clicking it > > on accident, or > > thinking that it's an affiliation mark, and not > > realizing that it gives > > full commit rights if granted. > > > > Turning it off simply removes the button, it wouldn't > > mean any change to > > our existing policies regarding earning of commit > > rights - applicants > > still need to get two patches reviewed, accepted, and > > landed and then > > contact one of the administrators to request > > access. (If we want to > > make this simpler later on, maybe one day we can rig up > > a form where > > they can enter the SHAs of their two patches.) > > > > Bryce > > > > ----------------------------------------------------- > > ------------------------- > > Check out the vibrant tech community on one of the > > world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slas > > hdot > > _______________________________________________ > > Inkscape-devel mailing list > > Inkscape-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/inkscape-d > > evel > > > > ------------------------------------------------------- > ----------------------- > Check out the vibrant tech community on one of the > world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashd > ot > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-dev > el
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Am 14.01.2018 um 13:03 schrieb Jabier Arraiza:
Hi, in git time maybe is better 2 patches substituted by 2 merge request ¿aproved?.
Any user can do a fork, start coding and submit a MR to the proyect. with or without access rights.
This is, I think, the git way to it, instead patches.
Also I couldent find the way to get in sync automaticaly my inkscape personal repo with inkscape one.
If this can be done by default, we can sugest leave in forks master branch clean and work with personal branches and MR.
This also reduce the number of branches in master (they realy not removed anyway you press remove it after MR merge.)
Cheers, J.
Hi Jabier,
your mail arrived just as I sent mine - and I fully agree. The workflow you describe is also the one I prefer (I actually use it myself most of the time - at the very least for larger code changes that have a regression risk).
However it really seems we need to improve our git documentation. I wasn't aware many of our developers were not used to it. For me it always felt like the "natural" way to do stuff whereas bzr always bugged me - seems many people actually feel the other way round. Also I always felt git was well documented but apparently people are struggling nonetheless, so a "copy+paste"-like section in the Wiki with the basic git commands tailored to work for the Inkscape project might be helpful.
There's one technical issue for which I'm currently not unhappy with people committing to the main branch: Unfortunately AppVeyor (CI provider for Windows builds) does not support building of GitLab merge requests yet, so currently only branches in the main repository will be built (unless one creates an AppVeyor account and enables builds for one's own repository which is why my own MRs are checked even though they are always committed to my own repository).
Best Regards, Eduard
Hi Eduard and all.
This AppVeyor could be a problem :(, maybe this can be bypassed by a temporary intermediate branch between the user branch MR and master.
Cheers, Jabier.
On Sun, 2018-01-14 at 13:52 +0100, Eduard Braun wrote:
Am 14.01.2018 um 13:03 schrieb Jabier Arraiza:
Hi, in git time maybe is better 2 patches substituted by 2 merge request ¿aproved?.
Any user can do a fork, start coding and submit a MR to the proyect. with or without access rights.
This is, I think, the git way to it, instead patches.
Also I couldent find the way to get in sync automaticaly my inkscape personal repo with inkscape one.
If this can be done by default, we can sugest leave in forks master branch clean and work with personal branches and MR.
This also reduce the number of branches in master (they realy not removed anyway you press remove it after MR merge.)
Cheers, J.
Hi Jabier,
your mail arrived just as I sent mine - and I fully agree. The workflow you describe is also the one I prefer (I actually use it myself most of the time - at the very least for larger code changes that have a regression risk).
However it really seems we need to improve our git documentation. I wasn't aware many of our developers were not used to it. For me it always felt like the "natural" way to do stuff whereas bzr always bugged me - seems many people actually feel the other way round. Also I always felt git was well documented but apparently people are struggling nonetheless, so a "copy+paste"-like section in the Wiki with the basic git commands tailored to work for the Inkscape project might be helpful.
There's one technical issue for which I'm currently not unhappy with people committing to the main branch: Unfortunately AppVeyor (CI provider for Windows builds) does not support building of GitLab merge requests yet, so currently only branches in the main repository will be built (unless one creates an AppVeyor account and enables builds for one's own repository which is why my own MRs are checked even though they are always committed to my own repository).
Best Regards, Eduard
Hi Jabier,
I'm not sure I understand. Unless I'm missing something this is not really something we can fix but something AppVeyor needs to implement on their side.
The relevant bug / feature request is https://github.com/appveyor/ci/issues/651
Actually this is the only feature I like about GitLab so far: As CI is built directly into GitLab cloning the CI configuration when forking a repo is enough to enable CI in one's own repository. Then again this is also what makes CI builds for our first-time contributors fail: The default time of 60 min is not enough to complete a build and it seems there is no possibility to change this default from our side.
Regards, Eduard
Am 14.01.2018 um 17:25 schrieb Jabier Arraiza:
Hi Eduard and all.
This AppVeyor could be a problem :(, maybe this can be bypassed by a temporary intermediate branch between the user branch MR and master.
Cheers, Jabier.
On Sun, 2018-01-14 at 13:52 +0100, Eduard Braun wrote:
Am 14.01.2018 um 13:03 schrieb Jabier Arraiza:
Hi, in git time maybe is better 2 patches substituted by 2 merge request ¿aproved?.
Any user can do a fork, start coding and submit a MR to the proyect. with or without access rights.
This is, I think, the git way to it, instead patches.
Also I couldent find the way to get in sync automaticaly my inkscape personal repo with inkscape one.
If this can be done by default, we can sugest leave in forks master branch clean and work with personal branches and MR.
This also reduce the number of branches in master (they realy not removed anyway you press remove it after MR merge.)
Cheers, J.
Hi Jabier,
your mail arrived just as I sent mine - and I fully agree. The workflow you describe is also the one I prefer (I actually use it myself most of the time - at the very least for larger code changes that have a regression risk).
However it really seems we need to improve our git documentation. I wasn't aware many of our developers were not used to it. For me it always felt like the "natural" way to do stuff whereas bzr always bugged me - seems many people actually feel the other way round. Also I always felt git was well documented but apparently people are struggling nonetheless, so a "copy+paste"-like section in the Wiki with the basic git commands tailored to work for the Inkscape project might be helpful.
There's one technical issue for which I'm currently not unhappy with people committing to the main branch: Unfortunately AppVeyor (CI provider for Windows builds) does not support building of GitLab merge requests yet, so currently only branches in the main repository will be built (unless one creates an AppVeyor account and enables builds for one's own repository which is why my own MRs are checked even though they are always committed to my own repository).
Best Regards, Eduard
Hi Eduard.
Im speaking on create a temp branch for each MR from "outside", inside inkscape main repo. Maybe is a overloaded option, maybe too complex... Just a idea, I not a expert.
Regards.
On Sun, 2018-01-14 at 17:41 +0100, Eduard Braun wrote:
Hi Jabier,
I'm not sure I understand. Unless I'm missing something this is not really something we can fix but something AppVeyor needs to implement on their side.
The relevant bug / feature request is https://github.com/appveyor/ci/issues/651
Actually this is the only feature I like about GitLab so far: As CI is built directly into GitLab cloning the CI configuration when forking a repo is enough to enable CI in one's own repository. Then again this is also what makes CI builds for our first-time contributors fail: The default time of 60 min is not enough to complete a build and it seems there is no possibility to change this default from our side.
Regards, Eduard
Am 14.01.2018 um 17:25 schrieb Jabier Arraiza:
Hi Eduard and all.
This AppVeyor could be a problem :(, maybe this can be bypassed by a temporary intermediate branch between the user branch MR and master.
Cheers, Jabier.
On Sun, 2018-01-14 at 13:52 +0100, Eduard Braun wrote:
Am 14.01.2018 um 13:03 schrieb Jabier Arraiza:
Hi, in git time maybe is better 2 patches substituted by 2 merge request ¿aproved?.
Any user can do a fork, start coding and submit a MR to the proyect. with or without access rights.
This is, I think, the git way to it, instead patches.
Also I couldent find the way to get in sync automaticaly my inkscape personal repo with inkscape one.
If this can be done by default, we can sugest leave in forks master branch clean and work with personal branches and MR.
This also reduce the number of branches in master (they realy not removed anyway you press remove it after MR merge.)
Cheers, J.
Hi Jabier,
your mail arrived just as I sent mine - and I fully agree. The workflow you describe is also the one I prefer (I actually use it myself most of the time - at the very least for larger code changes that have a regression risk).
However it really seems we need to improve our git documentation. I wasn't aware many of our developers were not used to it. For me it always felt like the "natural" way to do stuff whereas bzr always bugged me - seems many people actually feel the other way round. Also I always felt git was well documented but apparently people are struggling nonetheless, so a "copy+paste"-like section in the Wiki with the basic git commands tailored to work for the Inkscape project might be helpful.
There's one technical issue for which I'm currently not unhappy with people committing to the main branch: Unfortunately AppVeyor (CI provider for Windows builds) does not support building of GitLab merge requests yet, so currently only branches in the main repository will be built (unless one creates an AppVeyor account and enables builds for one's own repository which is why my own MRs are checked even though they are always committed to my own repository).
Best Regards, Eduard
Hi, in git time maybe is better 2 patches substituted by 2 merge request ¿aproved?.
Any user can do a fork, start coding and submit a MR to the proyect. with or without access rights.
This is, I think, the git way to it, instead patches.
Also I couldent find the way to get in sync automaticaly my inkscape personal repo with inkscape one.
If this can be done by default, we can sugest leave in forks master branch clean and work with personal branches and MR.
This also reduce the number of branches in master (they realy not removed anyway you press remove it after MR merge.)
Cheers, J.
On Sat, 2018-01-13 at 22:49 -0800, Bryce Harrington wrote:
On Sun, Jan 14, 2018 at 06:07:26AM +0100, Maren Hachmann wrote:
Mmmh - to find out if someone has contributed twice, one can go to https://gitlab.com/inkscape/inkscape/graphs/master, scroll down to bottom to be sure the page has fully loaded, and then use Ctrl+F with their user name on gitlab - or do some "git log
grep <email address or user name>" magic on the command line. Maybe
that wouldn't get all contributions, but well, there's a limit to what people can be expected to do for research, as you say.
Yep, if we could get that procedure scripted and automated, that'd be the main piece of a better access request tool.
The feature request I was talking about was about adding a reason when declining. Something like 'I'm not granting you access right now, because I cannot find your 2 required commits. Please contact us/me at .... if you know you fulfill our commit access criteria listed at ... (and introduce yourself on the mailing list)". Not about adding the option to write an 'application' - I looked at it from the outside, not from the side of the person who can grant access.
Ah, yes a rationale field like was in Launchpad, not a bad idea to request. Again though, most of the requests we get are not legitimate so it increases admin work a lot for not much benefit; an application field filled in by the user would be more positively helpful.
The thing about not being connected to the community is an issue that can't be solved with any of both mentioned features, though.
I worry that this change makes the project look 'closed' to outsiders (at least projects that do that give that impression to me), if there's nothing in the README, nor an up-to-date explanation anywhere how to become a project member. I think even people who have worked with a developer might not know how. Or do mentors routinely explain/offer this if not asked explicitly for info?
I'm not that worried about that. Inkscape's actually fairly liberal with commit access so most open source developers needing commit access are used to needing to engage directly with the community.
That said, improving the docs to this effect would be nice, as I mentioned before. Feel free to add mention where you think it should be.
Some day I'd like to restructure our new devel intro materials a bit better, defining our development principles and so on, and if no one gets around to it before then I'll do another take at the commit access request directions.
Meanwhile, just keep an eye out for new folks that are actively contributing and might make good candidates for commit access and give them a personal invite. (This is probably a far friendlier and better way to bring in new devs than a button, anyway.)
Btw. the 'Request access' button is still there at https://gitlab.com/inkscape/inkscape
Thanks, I've fixed that. Looks like the top-level settings don't get inherited. We should probably move the core codebases into an Inkscape Devels subteam, and I think that may let us standardize the settings for the code repos. I'll have to think on this.
(the Inkscape group is where it is disabled now)
I've updated the projects to conform. One thing I'm uncertain about is from the description it says that this increases certain restrictions on anonymous users which may or may not be what we want. If access to anything seems to have gotten more restrictive in a bad way, let me know and I'll make adjustments.
Thanks again for reviewing this change and providing feedback. And like I mentioned, if anyone spots any serious issues with it going forward let me know and we can re-evaluate.
Bryce
Maren
Am 14.01.2018 um 05:22 schrieb Bryce Harrington:
On Sun, Jan 14, 2018 at 04:39:17AM +0100, Maren Hachmann wrote:
Could someone add a link to the info about how to join/participate to the README?
After following a detour via 'CONTRIBUTING', which would be a symlink locally, but just had a path printed inside on gitlab, I found a description here: https://gitlab.com/inkscape/inkscape/blob/master/doc/HACKING.tx t
I think that file also needs an update, telling users *how* to 'request access' now that the option via button is closed.
(what would have been the issue with just declining any non- contributor join requests? Not being able to add an explanatory note? Perhaps make this a gitlab feature request?)
Right, there is no explanation included in the requests. So there's not an easy way to tell if someone has contributed patches, whether they've been accepted, or etc. I suspect no one getting these notices knows what to do with them, so they've been just piling up; I sometimes do some sleuthing around to see if the individual has done anything with Inkscape, but it's time consuming to chase down their contribution history from scratch. The only practical way that applying works is if the applicant has been working with a developer and that developer knows they're applying for access -- in which case the developer can just add them directly, no need for the applicant to also click the button.
We had a similar problem with Launchpad, although there it had a feedback form to send the applicant an email directing them as to what they'd need to do. Also, in LP it was a bit fewer clicks to identify what they did for Inkscape, although it was still ambiguous if they'd gone through the proper process.
You are right that this could use better documentation. The HACKING file is a good start.
In general, I think most people who need commit access will be hooking in enough with the project and the rest of the developers that someone will help them get it, without needing a lot of structure. (If they're not hooked in to that level, well might not be a good candidate for giving commit rights anyway...) So I think for now, just having people ask on the inkscape-devel@ list or IRC for commit access is going to be sufficient, basically similar to how we handle wiki access.
I don't know if it is worth bothering asking for our process as a gitlab feature request, as we may be kind of unique with this. In any case I suspect it's not that hard for us to implement some web UI ourselves to accomplish the same goal, if it really bothers us.
Blue sky, maybe someday we could have some sort of unified membership access request form, to request wiki access, commit access, travel sponsorship, et al. And a corresponding administrative side page to review/comment/approve applications. It would be nice if that app had a way to programmatically tell if the user had fulfilled whatever requirements are set for access (i.e. the 2-patch rule, length of time in the project, etc.) If anyone wishes to work on such a web form, I can share further ideas, but I think we can handle things manually for the time being.
Bryce
Maren
Am 14.01.2018 um 03:29 schrieb Bryce Harrington:
I've proceeded ahead and made this config change to gitlab. Let me know if anyone spots any issues with this change.
Bryce
On Sat, Jan 13, 2018 at 09:10:59AM -0800, Bryce Harrington wrote:
On Sat, Jan 13, 2018 at 09:32:03AM +0100, Marc Jeanmougin wrote: > No objection from me, sounds nice (I did not know we > could remove the > button^^); what I tried to do at some point was to give > "Guest" role to > those users (which does not grant any right)
I also wondered about establishing an Inkscape Users subgroup that people could voluntarily add themselves to. (This might be worth doing regardless, particularly if we have some utility for it beyond just affiliation.)
Bryce
> On 01/13/2018 06:28 AM, Bryce Harrington wrote: > > There's a setting "Allow users to request access" on > > our Inkscape main > > group (https://gitlab.com/inkscape).%C2%A0%C2%A0I%27d like to > > switch it to 'off'. > > Are there any objections if I did this? > > > > This setting adds a button to our website for logged in > > users to push to > > send an email to our admins asking for membership to > > the inkscape main > > group. The effect of this gives them commit access on > > the inkscape repo > > (and I suspect maybe other git repos in subgroups; I'm > > not sure how the > > permissions propagate.) > > > > This was useful initially when everyone was needing > > gitlab access, but I > > think all the existing committers that want it have > > it. These days the > > requests we're getting are mostly from people with no > > registered > > activity related to Inkscape; we've been getting a > > handful of these > > invalid requests each month. Maybe they're clicking it > > on accident, or > > thinking that it's an affiliation mark, and not > > realizing that it gives > > full commit rights if granted. > > > > Turning it off simply removes the button, it wouldn't > > mean any change to > > our existing policies regarding earning of commit > > rights - applicants > > still need to get two patches reviewed, accepted, and > > landed and then > > contact one of the administrators to request > > access. (If we want to > > make this simpler later on, maybe one day we can rig up > > a form where > > they can enter the SHAs of their two patches.) > > > > Bryce > > > > ----------------------------------------------------- > > ------------------------- > > Check out the vibrant tech community on one of the > > world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slas > > hdot > > _______________________________________________ > > Inkscape-devel mailing list > > Inkscape-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/inkscape-d > > evel > > > > ------------------------------------------------------- > ----------------------- > Check out the vibrant tech community on one of the > world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashd > ot > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-dev > el
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
A general comment:
While it's nice the Inkscape project is that open and gives commit access to contributors after two commits -- IMHO it's completely unnecessary!
No other project I contribute to grants commit access to the main repository to occasional contributors. The widely accepted way is to create a merge request with at least one core member of the project reviewing the code subsequently and a merge once the feature is finished (Basically what "git flow" is all about). This works extremely well and basically this is how we're already doing it most of the time - the people who seem to miss commit access to the main repo appear to be mostly those who are used to committing directly to the main repository from the old Bazaar days whereas new contributors are typically fine with creating merge requests and do not even think of asking for commit access.
As a matter of fact, when I first started contributing to the project I did exactly that: I created a merge request and waited for somebody to review it (unfortunately back then reviewing merge requests was not a top priority, so it was not a great first experience - that's obviously the one thing we need to avoid). Funnily Nicolas asked me to request commit access immediately after - which actually surprised me (I was not used to it) and also frightened me a bit (as a new project member I would have preferred people looking over my commits - I still do - instead of pushing whatever I came up with directly to the repo potentially breaking something). Given the long wait time I experienced before I understood it, though, and tried to operate with care. Still I very much welcome that reviewing merge request became more common now that we are on GitLab and I personally make heave use of it.
Long story short - I don't think it's a problem if there's not an obvious way to request commit access. It's not required for contributing code and those who actually feel they could profit from commit access will eventually ask for it or - in turn - could be granted access automatically without having to request it.
Best Regards, Eduard
Am 14.01.2018 um 07:49 schrieb Bryce Harrington:
On Sun, Jan 14, 2018 at 06:07:26AM +0100, Maren Hachmann wrote:
Mmmh - to find out if someone has contributed twice, one can go to https://gitlab.com/inkscape/inkscape/graphs/master, scroll down to bottom to be sure the page has fully loaded, and then use Ctrl+F with their user name on gitlab - or do some "git log | grep <email address or user name>" magic on the command line. Maybe that wouldn't get all contributions, but well, there's a limit to what people can be expected to do for research, as you say.
Yep, if we could get that procedure scripted and automated, that'd be the main piece of a better access request tool.
The feature request I was talking about was about adding a reason when declining. Something like 'I'm not granting you access right now, because I cannot find your 2 required commits. Please contact us/me at .... if you know you fulfill our commit access criteria listed at ... (and introduce yourself on the mailing list)". Not about adding the option to write an 'application' - I looked at it from the outside, not from the side of the person who can grant access.
Ah, yes a rationale field like was in Launchpad, not a bad idea to request. Again though, most of the requests we get are not legitimate so it increases admin work a lot for not much benefit; an application field filled in by the user would be more positively helpful.
The thing about not being connected to the community is an issue that can't be solved with any of both mentioned features, though.
I worry that this change makes the project look 'closed' to outsiders (at least projects that do that give that impression to me), if there's nothing in the README, nor an up-to-date explanation anywhere how to become a project member. I think even people who have worked with a developer might not know how. Or do mentors routinely explain/offer this if not asked explicitly for info?
I'm not that worried about that. Inkscape's actually fairly liberal with commit access so most open source developers needing commit access are used to needing to engage directly with the community.
That said, improving the docs to this effect would be nice, as I mentioned before. Feel free to add mention where you think it should be.
Some day I'd like to restructure our new devel intro materials a bit better, defining our development principles and so on, and if no one gets around to it before then I'll do another take at the commit access request directions.
Meanwhile, just keep an eye out for new folks that are actively contributing and might make good candidates for commit access and give them a personal invite. (This is probably a far friendlier and better way to bring in new devs than a button, anyway.)
Btw. the 'Request access' button is still there at https://gitlab.com/inkscape/inkscape
Thanks, I've fixed that. Looks like the top-level settings don't get inherited. We should probably move the core codebases into an Inkscape Devels subteam, and I think that may let us standardize the settings for the code repos. I'll have to think on this.
(the Inkscape group is where it is disabled now)
I've updated the projects to conform. One thing I'm uncertain about is from the description it says that this increases certain restrictions on anonymous users which may or may not be what we want. If access to anything seems to have gotten more restrictive in a bad way, let me know and I'll make adjustments.
Thanks again for reviewing this change and providing feedback. And like I mentioned, if anyone spots any serious issues with it going forward let me know and we can re-evaluate.
Bryce
Maren
Am 14.01.2018 um 05:22 schrieb Bryce Harrington:
On Sun, Jan 14, 2018 at 04:39:17AM +0100, Maren Hachmann wrote:
Could someone add a link to the info about how to join/participate to the README?
After following a detour via 'CONTRIBUTING', which would be a symlink locally, but just had a path printed inside on gitlab, I found a description here: https://gitlab.com/inkscape/inkscape/blob/master/doc/HACKING.txt
I think that file also needs an update, telling users *how* to 'request access' now that the option via button is closed.
(what would have been the issue with just declining any non-contributor join requests? Not being able to add an explanatory note? Perhaps make this a gitlab feature request?)
Right, there is no explanation included in the requests. So there's not an easy way to tell if someone has contributed patches, whether they've been accepted, or etc. I suspect no one getting these notices knows what to do with them, so they've been just piling up; I sometimes do some sleuthing around to see if the individual has done anything with Inkscape, but it's time consuming to chase down their contribution history from scratch. The only practical way that applying works is if the applicant has been working with a developer and that developer knows they're applying for access -- in which case the developer can just add them directly, no need for the applicant to also click the button.
We had a similar problem with Launchpad, although there it had a feedback form to send the applicant an email directing them as to what they'd need to do. Also, in LP it was a bit fewer clicks to identify what they did for Inkscape, although it was still ambiguous if they'd gone through the proper process.
You are right that this could use better documentation. The HACKING file is a good start.
In general, I think most people who need commit access will be hooking in enough with the project and the rest of the developers that someone will help them get it, without needing a lot of structure. (If they're not hooked in to that level, well might not be a good candidate for giving commit rights anyway...) So I think for now, just having people ask on the inkscape-devel@ list or IRC for commit access is going to be sufficient, basically similar to how we handle wiki access.
I don't know if it is worth bothering asking for our process as a gitlab feature request, as we may be kind of unique with this. In any case I suspect it's not that hard for us to implement some web UI ourselves to accomplish the same goal, if it really bothers us.
Blue sky, maybe someday we could have some sort of unified membership access request form, to request wiki access, commit access, travel sponsorship, et al. And a corresponding administrative side page to review/comment/approve applications. It would be nice if that app had a way to programmatically tell if the user had fulfilled whatever requirements are set for access (i.e. the 2-patch rule, length of time in the project, etc.) If anyone wishes to work on such a web form, I can share further ideas, but I think we can handle things manually for the time being.
Bryce
Maren
Am 14.01.2018 um 03:29 schrieb Bryce Harrington:
I've proceeded ahead and made this config change to gitlab. Let me know if anyone spots any issues with this change.
Bryce
On Sat, Jan 13, 2018 at 09:10:59AM -0800, Bryce Harrington wrote:
On Sat, Jan 13, 2018 at 09:32:03AM +0100, Marc Jeanmougin wrote: > No objection from me, sounds nice (I did not know we could remove the > button^^); what I tried to do at some point was to give "Guest" role to > those users (which does not grant any right) I also wondered about establishing an Inkscape Users subgroup that people could voluntarily add themselves to. (This might be worth doing regardless, particularly if we have some utility for it beyond just affiliation.)
Bryce
> On 01/13/2018 06:28 AM, Bryce Harrington wrote: >> There's a setting "Allow users to request access" on our Inkscape main >> group (https://gitlab.com/inkscape). I'd like to switch it to 'off'. >> Are there any objections if I did this? >> >> This setting adds a button to our website for logged in users to push to >> send an email to our admins asking for membership to the inkscape main >> group. The effect of this gives them commit access on the inkscape repo >> (and I suspect maybe other git repos in subgroups; I'm not sure how the >> permissions propagate.) >> >> This was useful initially when everyone was needing gitlab access, but I >> think all the existing committers that want it have it. These days the >> requests we're getting are mostly from people with no registered >> activity related to Inkscape; we've been getting a handful of these >> invalid requests each month. Maybe they're clicking it on accident, or >> thinking that it's an affiliation mark, and not realizing that it gives >> full commit rights if granted. >> >> Turning it off simply removes the button, it wouldn't mean any change to >> our existing policies regarding earning of commit rights - applicants >> still need to get two patches reviewed, accepted, and landed and then >> contact one of the administrators to request access. (If we want to >> make this simpler later on, maybe one day we can rig up a form where >> they can enter the SHAs of their two patches.) >> >> Bryce >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Inkscape-devel mailing list >> Inkscape-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/inkscape-devel >> > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Answering all in one email, sorry about that.
Am 14.01.2018 um 13:33 schrieb Eduard Braun:
Still I very much welcome that reviewing merge request became more common now that we are on GitLab and I personally make heave use of it.
- Yes, except for trivial changes, I also wouldn't use it.
Long story short - I don't think it's a problem if there's not an obvious way to request commit access. It's not required for contributing code and those who actually feel they could profit from commit access will eventually ask for it or - in turn - could be granted access automatically without having to request it.
- Having that path documented somewhere will still help. I didn't ask for adding the button back, but just for someone to put in info about the process in a place which doesn't require you to click through 5 pages if you do it via gitlab interface.
I don't think that I should be that someone, Bryce - it should be someone who's actually involved with it.
It seems there's also still some discussion needed, for settling the details. I like Martin's mentor suggestion, too, I've benefitted from such a procedure myself.
Am 14.01.2018 um 13:52 schrieb Eduard Braun:
so a "copy+paste"-like section in the Wiki with the basic git commands tailored to work for the Inkscape project might be helpful
There is a Wiki page about git, Eduard - do you think it needs more content (you wrote some of it, so I think you're aware of it)? http://wiki.inkscape.org/wiki/index.php/Working_with_Git
The website also has docs: https://inkscape.org/en/develop/getting-started/ https://inkscape.org/en/develop/inkscape-git/
Am 14.01.2018 um 13:03 schrieb Jabier Arraiza:
Also I couldent find the way to get in sync automaticaly my inkscape personal repo with inkscape one.
Jabier, repo syncing is documented here: https://about.gitlab.com/2016/12/01/how-to-keep-your-fork-up-to-date-with-it... https://docs.gitlab.com/ee/workflow/repository_mirroring.html
Docs say that branches you've worked on won't be updated (which would be a rebase, or an overwrite, so it's good they aren't).
The use cases gitlab offers for mirroring are more or less archiving use cases, though, not development. They say:
"Instead, any commits should be pushed to the upstream repository"
(this is under the assumption that you're the owner of upstream.)
Not sure if the new option "Pull only protected branches" changes anything about this, but it might make cloning and pulling faster :)
Maren
Best Regards, Eduard
Am 14.01.2018 um 07:49 schrieb Bryce Harrington:
On Sun, Jan 14, 2018 at 06:07:26AM +0100, Maren Hachmann wrote:
Mmmh - to find out if someone has contributed twice, one can go to https://gitlab.com/inkscape/inkscape/graphs/master, scroll down to bottom to be sure the page has fully loaded, and then use Ctrl+F with their user name on gitlab - or do some "git log | grep <email address or user name>" magic on the command line. Maybe that wouldn't get all contributions, but well, there's a limit to what people can be expected to do for research, as you say.
Yep, if we could get that procedure scripted and automated, that'd be the main piece of a better access request tool.
The feature request I was talking about was about adding a reason when declining. Something like 'I'm not granting you access right now, because I cannot find your 2 required commits. Please contact us/me at .... if you know you fulfill our commit access criteria listed at ... (and introduce yourself on the mailing list)". Not about adding the option to write an 'application' - I looked at it from the outside, not from the side of the person who can grant access.
Ah, yes a rationale field like was in Launchpad, not a bad idea to request. Again though, most of the requests we get are not legitimate so it increases admin work a lot for not much benefit; an application field filled in by the user would be more positively helpful.
The thing about not being connected to the community is an issue that can't be solved with any of both mentioned features, though.
I worry that this change makes the project look 'closed' to outsiders (at least projects that do that give that impression to me), if there's nothing in the README, nor an up-to-date explanation anywhere how to become a project member. I think even people who have worked with a developer might not know how. Or do mentors routinely explain/offer this if not asked explicitly for info?
I'm not that worried about that. Inkscape's actually fairly liberal with commit access so most open source developers needing commit access are used to needing to engage directly with the community.
That said, improving the docs to this effect would be nice, as I mentioned before. Feel free to add mention where you think it should be.
Some day I'd like to restructure our new devel intro materials a bit better, defining our development principles and so on, and if no one gets around to it before then I'll do another take at the commit access request directions.
Meanwhile, just keep an eye out for new folks that are actively contributing and might make good candidates for commit access and give them a personal invite. (This is probably a far friendlier and better way to bring in new devs than a button, anyway.)
Btw. the 'Request access' button is still there at https://gitlab.com/inkscape/inkscape
Thanks, I've fixed that. Looks like the top-level settings don't get inherited. We should probably move the core codebases into an Inkscape Devels subteam, and I think that may let us standardize the settings for the code repos. I'll have to think on this.
(the Inkscape group is where it is disabled now)
I've updated the projects to conform. One thing I'm uncertain about is from the description it says that this increases certain restrictions on anonymous users which may or may not be what we want. If access to anything seems to have gotten more restrictive in a bad way, let me know and I'll make adjustments.
Thanks again for reviewing this change and providing feedback. And like I mentioned, if anyone spots any serious issues with it going forward let me know and we can re-evaluate.
Bryce
Maren
Am 14.01.2018 um 05:22 schrieb Bryce Harrington:
On Sun, Jan 14, 2018 at 04:39:17AM +0100, Maren Hachmann wrote:
Could someone add a link to the info about how to join/participate to the README?
After following a detour via 'CONTRIBUTING', which would be a symlink locally, but just had a path printed inside on gitlab, I found a description here: https://gitlab.com/inkscape/inkscape/blob/master/doc/HACKING.txt
I think that file also needs an update, telling users *how* to 'request access' now that the option via button is closed.
(what would have been the issue with just declining any non-contributor join requests? Not being able to add an explanatory note? Perhaps make this a gitlab feature request?)
Right, there is no explanation included in the requests. So there's not an easy way to tell if someone has contributed patches, whether they've been accepted, or etc. I suspect no one getting these notices knows what to do with them, so they've been just piling up; I sometimes do some sleuthing around to see if the individual has done anything with Inkscape, but it's time consuming to chase down their contribution history from scratch. The only practical way that applying works is if the applicant has been working with a developer and that developer knows they're applying for access -- in which case the developer can just add them directly, no need for the applicant to also click the button.
We had a similar problem with Launchpad, although there it had a feedback form to send the applicant an email directing them as to what they'd need to do. Also, in LP it was a bit fewer clicks to identify what they did for Inkscape, although it was still ambiguous if they'd gone through the proper process.
You are right that this could use better documentation. The HACKING file is a good start.
In general, I think most people who need commit access will be hooking in enough with the project and the rest of the developers that someone will help them get it, without needing a lot of structure. (If they're not hooked in to that level, well might not be a good candidate for giving commit rights anyway...) So I think for now, just having people ask on the inkscape-devel@ list or IRC for commit access is going to be sufficient, basically similar to how we handle wiki access.
I don't know if it is worth bothering asking for our process as a gitlab feature request, as we may be kind of unique with this. In any case I suspect it's not that hard for us to implement some web UI ourselves to accomplish the same goal, if it really bothers us.
Blue sky, maybe someday we could have some sort of unified membership access request form, to request wiki access, commit access, travel sponsorship, et al. And a corresponding administrative side page to review/comment/approve applications. It would be nice if that app had a way to programmatically tell if the user had fulfilled whatever requirements are set for access (i.e. the 2-patch rule, length of time in the project, etc.) If anyone wishes to work on such a web form, I can share further ideas, but I think we can handle things manually for the time being.
Bryce
Maren
Am 14.01.2018 um 03:29 schrieb Bryce Harrington:
I've proceeded ahead and made this config change to gitlab. Let me know if anyone spots any issues with this change.
Bryce
On Sat, Jan 13, 2018 at 09:10:59AM -0800, Bryce Harrington wrote: > On Sat, Jan 13, 2018 at 09:32:03AM +0100, Marc Jeanmougin wrote: >> No objection from me, sounds nice (I did not know we could >> remove the >> button^^); what I tried to do at some point was to give "Guest" >> role to >> those users (which does not grant any right) > I also wondered about establishing an Inkscape Users subgroup that > people could voluntarily add themselves to. (This might be worth > doing > regardless, particularly if we have some utility for it beyond just > affiliation.) > > Bryce > >> On 01/13/2018 06:28 AM, Bryce Harrington wrote: >>> There's a setting "Allow users to request access" on our >>> Inkscape main >>> group (https://gitlab.com/inkscape).%C2%A0 I'd like to switch it to >>> 'off'. >>> Are there any objections if I did this? >>> >>> This setting adds a button to our website for logged in users >>> to push to >>> send an email to our admins asking for membership to the >>> inkscape main >>> group. The effect of this gives them commit access on the >>> inkscape repo >>> (and I suspect maybe other git repos in subgroups; I'm not sure >>> how the >>> permissions propagate.) >>> >>> This was useful initially when everyone was needing gitlab >>> access, but I >>> think all the existing committers that want it have it. These >>> days the >>> requests we're getting are mostly from people with no registered >>> activity related to Inkscape; we've been getting a handful of >>> these >>> invalid requests each month. Maybe they're clicking it on >>> accident, or >>> thinking that it's an affiliation mark, and not realizing that >>> it gives >>> full commit rights if granted. >>> >>> Turning it off simply removes the button, it wouldn't mean any >>> change to >>> our existing policies regarding earning of commit rights - >>> applicants >>> still need to get two patches reviewed, accepted, and landed >>> and then >>> contact one of the administrators to request access. (If we >>> want to >>> make this simpler later on, maybe one day we can rig up a form >>> where >>> they can enter the SHAs of their two patches.) >>> >>> Bryce >>> >>> ------------------------------------------------------------------------------ >>> >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Inkscape-devel mailing list >>> Inkscape-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel >>> >> ------------------------------------------------------------------------------ >> >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Inkscape-devel mailing list >> Inkscape-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/inkscape-devel > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Am 15.01.2018 um 01:51 schrieb Maren Hachmann:
Am 14.01.2018 um 13:52 schrieb Eduard Braun:
so a "copy+paste"-like section in the Wiki with the basic git commands tailored to work for the Inkscape project might be helpful
There is a Wiki page about git, Eduard - do you think it needs more content (you wrote some of it, so I think you're aware of it)? http://wiki.inkscape.org/wiki/index.php/Working_with_Git
The website also has docs: https://inkscape.org/en/develop/getting-started/ https://inkscape.org/en/develop/inkscape-git/
Yes, I'm aware of the Wiki page ;-) Assuming others are too (I hope they are) it seems it is not as helpful as one might hope for, though (otherwise I can't explain the repeating questions on basic git functionality).
The wiki page mainly lists a lot of git commands without much further explanation. The pages on the website only address the question "how do I get the code?" but nothing beyond that.
I can only guess but I assume we might need to explain some typical workflows like - "How do I update my local repository" - "How do I update my fork?" - "How do I get my local copy (with local changes) synced with upstream?" - "How do I checkout a specific MR / remote commit into my own tree?" - "How do I merge my feature branch into master?" along with real world example commands (i.e. full commands including URLs and all necessary parameters to make it actually work). Also explaining some best practices might help, like rebasing, squashing, "pull vs pull --rebase", why merging master should be avoided, etc...
Like a lot of documentation this is on my never ending todo list (or rather the "would be nice to have" list) so I'm not sure if I will get to it eventually (especially given the fact it's not the most rewarding activity and I have a feeling that the most frustrated git users are also those wo chose not to try to hard understanding git to begin with ;-) ).
Best Regards, Eduard
Yes, I'm aware of the Wiki page ;-) Assuming others are too (I hope they are) it seems it is not as helpful as one might hope for, though (otherwise I can't explain the repeating questions on basic git functionality).
I think part of the problem may be that the link to the Wiki page (http://wiki.inkscape.org/wiki/index.php/Working_with_Git) seems to be not very easy to find.
Starting from the main site at: https://inkscape.org/en/ I tried to find the Wiki-git page as follows: I went to the link Develop->Develop and found the link to the Inkscape Wiki page: http://wiki.inkscape.org/wiki/index.php/Inkscape
Here I scanned the entire first screen and saw no reference to git, so I gave up. It was only later, when I was already somewhat frustrated, that I found the link by scrolling down to where it says "Working with Git". So I found the link, but only because I already had prior knowledge that the link actually existed. Inkscape_Wiki.png http://inkscape.13.x6.nabble.com/file/t148043/Inkscape_Wiki.png - I think it would be helpful if the link to git commands were visible on the attached screenshot. - I think it would also be helpful to have few sentences outlining what can be done directly in Gitlab on the web without using git at all, since the Gitlab user-interface is considerably less intimidating than git is.
hth, Alvin
-- Sent from: http://inkscape.13.x6.nabble.com/Inkscape-Dev-f2781808.html
Morning Bryce, Maren,
If an apprentice style system is considered, we might find that it gives us more potent contributors anyway.
The help that an experienced project contributor can give to a new entrant can be invaluable in removing potentially days worth of blockers, frustrations and also being in the right place to offer encouragement and getting developers plugged into the social community faster.
If the documentation expressed this method as the default and the lone wolf hit and run as the alternative, we might do better overall. Details bout joining the gitlab group would then be matters for the mentors rather than the contributors.
Best Regards, Martin Owens
On Sat, 2018-01-13 at 20:22 -0800, Bryce Harrington wrote:
On Sun, Jan 14, 2018 at 04:39:17AM +0100, Maren Hachmann wrote:
Could someone add a link to the info about how to join/participate to the README?
After following a detour via 'CONTRIBUTING', which would be a symlink locally, but just had a path printed inside on gitlab, I found a description here: https://gitlab.com/inkscape/inkscape/blob/master/doc/HACKING.txt
I think that file also needs an update, telling users *how* to 'request access' now that the option via button is closed.
(what would have been the issue with just declining any non- contributor join requests? Not being able to add an explanatory note? Perhaps make this a gitlab feature request?)
Right, there is no explanation included in the requests. So there's not an easy way to tell if someone has contributed patches, whether they've been accepted, or etc. I suspect no one getting these notices knows what to do with them, so they've been just piling up; I sometimes do some sleuthing around to see if the individual has done anything with Inkscape, but it's time consuming to chase down their contribution history from scratch. The only practical way that applying works is if the applicant has been working with a developer and that developer knows they're applying for access -- in which case the developer can just add them directly, no need for the applicant to also click the button.
We had a similar problem with Launchpad, although there it had a feedback form to send the applicant an email directing them as to what they'd need to do. Also, in LP it was a bit fewer clicks to identify what they did for Inkscape, although it was still ambiguous if they'd gone through the proper process.
You are right that this could use better documentation. The HACKING file is a good start.
In general, I think most people who need commit access will be hooking in enough with the project and the rest of the developers that someone will help them get it, without needing a lot of structure. (If they're not hooked in to that level, well might not be a good candidate for giving commit rights anyway...) So I think for now, just having people ask on the inkscape-devel@ list or IRC for commit access is going to be sufficient, basically similar to how we handle wiki access.
I don't know if it is worth bothering asking for our process as a gitlab feature request, as we may be kind of unique with this. In any case I suspect it's not that hard for us to implement some web UI ourselves to accomplish the same goal, if it really bothers us.
Blue sky, maybe someday we could have some sort of unified membership access request form, to request wiki access, commit access, travel sponsorship, et al. And a corresponding administrative side page to review/comment/approve applications. It would be nice if that app had a way to programmatically tell if the user had fulfilled whatever requirements are set for access (i.e. the 2-patch rule, length of time in the project, etc.) If anyone wishes to work on such a web form, I can share further ideas, but I think we can handle things manually for the time being.
Bryce
Maren
Am 14.01.2018 um 03:29 schrieb Bryce Harrington:
I've proceeded ahead and made this config change to gitlab. Let me know if anyone spots any issues with this change.
Bryce
On Sat, Jan 13, 2018 at 09:10:59AM -0800, Bryce Harrington wrote:
On Sat, Jan 13, 2018 at 09:32:03AM +0100, Marc Jeanmougin wrote:
No objection from me, sounds nice (I did not know we could remove the button^^); what I tried to do at some point was to give "Guest" role to those users (which does not grant any right)
I also wondered about establishing an Inkscape Users subgroup that people could voluntarily add themselves to. (This might be worth doing regardless, particularly if we have some utility for it beyond just affiliation.)
Bryce
On 01/13/2018 06:28 AM, Bryce Harrington wrote:
There's a setting "Allow users to request access" on our Inkscape main group (https://gitlab.com/inkscape).%C2%A0%C2%A0I%27d like to switch it to 'off'. Are there any objections if I did this?
This setting adds a button to our website for logged in users to push to send an email to our admins asking for membership to the inkscape main group. The effect of this gives them commit access on the inkscape repo (and I suspect maybe other git repos in subgroups; I'm not sure how the permissions propagate.)
This was useful initially when everyone was needing gitlab access, but I think all the existing committers that want it have it. These days the requests we're getting are mostly from people with no registered activity related to Inkscape; we've been getting a handful of these invalid requests each month. Maybe they're clicking it on accident, or thinking that it's an affiliation mark, and not realizing that it gives full commit rights if granted.
Turning it off simply removes the button, it wouldn't mean any change to our existing policies regarding earning of commit rights - applicants still need to get two patches reviewed, accepted, and landed and then contact one of the administrators to request access. (If we want to make this simpler later on, maybe one day we can rig up a form where they can enter the SHAs of their two patches.)
Bryce
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (7)
-
alvinpenner -
Bryce Harrington -
Eduard Braun -
Jabier Arraiza -
Marc Jeanmougin -
Maren Hachmann -
Martin Owens