Turning off gitlab's "Allow users to request access"?

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Turning off gitlab's "Allow users to request access"?

Bryce Harrington-3
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turning off gitlab's "Allow users to request access"?

Marc Jeanmougin
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)

--
Mc

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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turning off gitlab's "Allow users to request access"?

Bryce Harrington-3
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
> > [hidden email]
> > 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turning off gitlab's "Allow users to request access"?

Bryce Harrington-3
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
> > > [hidden email]
> > > 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
> > [hidden email]
> > 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turning off gitlab's "Allow users to request access"?

Maren Hachmann
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
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turning off gitlab's "Allow users to request access"?

Bryce Harrington-3
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
> >>>> [hidden email]
> >>>> 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
> >>> [hidden email]
> >>> 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
> >> [hidden email]
> >> 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
> > [hidden email]
> > 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turning off gitlab's "Allow users to request access"?

Maren Hachmann
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
>>>>>> [hidden email]
>>>>>> 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
>>>>> [hidden email]
>>>>> 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
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turning off gitlab's "Allow users to request access"?

Bryce Harrington-3
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
> >>>>>> [hidden email]
> >>>>>> 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
> >>>>> [hidden email]
> >>>>> 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
> >>>> [hidden email]
> >>>> 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
> >>> [hidden email]
> >>> 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
> >> [hidden email]
> >> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turning off gitlab's "Allow users to request access"?

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.



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).  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/slas
> > > > > > > > hdot
> > > > > > > > _______________________________________________
> > > > > > > > Inkscape-devel mailing list
> > > > > > > > [hidden email]
> > > > > > > > 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
> > > > > > > [hidden email]
> > > > > > > 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
> > > > > > [hidden email]
> > > > > > 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
> > > > > [hidden email]
> > > > > 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
> > > > [hidden email]
> > > > 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Turning off gitlab's "Allow users to request access"?

Jabier Arraiza
In reply to this post by Bryce Harrington-3
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).  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/slas
> > > > > > > > hdot
> > > > > > > > _______________________________________________
> > > > > > > > Inkscape-devel mailing list
> > > > > > > > [hidden email]
> > > > > > > > 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
> > > > > > > [hidden email]
> > > > > > > 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
> > > > > > [hidden email]
> > > > > > 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
> > > > > [hidden email]
> > > > > 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
> > > > [hidden email]
> > > > 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Turning off gitlab's "Allow users to request access"?

Patrick Storz
In reply to this post by Bryce Harrington-3
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
>>>>>>>> [hidden email]
>>>>>>>> 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
>>>>>>> [hidden email]
>>>>>>> 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
>>>>>> [hidden email]
>>>>>> 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
>>>>> [hidden email]
>>>>> 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
>>>> [hidden email]
>>>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turning off gitlab's "Allow users to request access"?

Patrick Storz
In reply to this post by Jabier Arraiza
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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turning off gitlab's "Allow users to request access"?

doctormo
In reply to this post by Bryce Harrington-3
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).  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
> > > > > > [hidden email]
> > > > > > 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
> > > > > [hidden email]
> > > > > 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
> > > > [hidden email]
> > > > 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
> > > [hidden email]
> > > 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
> > [hidden email]
> > 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turning off gitlab's "Allow users to request access"?

Jabier Arraiza
In reply to this post by Patrick Storz
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
------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Turning off gitlab's "Allow users to request access"?

Patrick Storz
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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turning off gitlab's "Allow users to request access"?

Jabier Arraiza
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
>
>
------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Turning off gitlab's "Allow users to request access"?

Maren Hachmann
In reply to this post by Patrick Storz
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-its-origin/
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).  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
>>>>>>>>> [hidden email]
>>>>>>>>> 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
>>>>>>>> [hidden email]
>>>>>>>> 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
>>>>>>> [hidden email]
>>>>>>> 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
>>>>>> [hidden email]
>>>>>> 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
>>>>> [hidden email]
>>>>> 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
>> [hidden email]
>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turning off gitlab's "Allow users to request access"?

Patrick Storz
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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Turning off gitlab's "Allow users to request access"?

alvinpenner
>>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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel