Hi, in git time maybe is better 2 patches substituted by 2 merge request ¿aproved?.
Any user can do a fork, start coding and submit a MR to the proyect. with or without access rights.
This is, I think, the git way to it, instead patches.
Also I couldent find the way to get in sync automaticaly my inkscape personal repo with inkscape one.
If this can be done by default, we can sugest leave in forks master branch clean and work with personal branches and MR.
This also reduce the number of branches in master (they realy not removed anyway you press remove it after MR merge.)
Cheers, J.
On Sat, 2018-01-13 at 22:49 -0800, Bryce Harrington wrote:
On Sun, Jan 14, 2018 at 06:07:26AM +0100, Maren Hachmann wrote:
Mmmh - to find out if someone has contributed twice, one can go to https://gitlab.com/inkscape/inkscape/graphs/master, scroll down to bottom to be sure the page has fully loaded, and then use Ctrl+F with their user name on gitlab - or do some "git log
grep <email address or user name>" magic on the command line. Maybe
that wouldn't get all contributions, but well, there's a limit to what people can be expected to do for research, as you say.
Yep, if we could get that procedure scripted and automated, that'd be the main piece of a better access request tool.
The feature request I was talking about was about adding a reason when declining. Something like 'I'm not granting you access right now, because I cannot find your 2 required commits. Please contact us/me at .... if you know you fulfill our commit access criteria listed at ... (and introduce yourself on the mailing list)". Not about adding the option to write an 'application' - I looked at it from the outside, not from the side of the person who can grant access.
Ah, yes a rationale field like was in Launchpad, not a bad idea to request. Again though, most of the requests we get are not legitimate so it increases admin work a lot for not much benefit; an application field filled in by the user would be more positively helpful.
The thing about not being connected to the community is an issue that can't be solved with any of both mentioned features, though.
I worry that this change makes the project look 'closed' to outsiders (at least projects that do that give that impression to me), if there's nothing in the README, nor an up-to-date explanation anywhere how to become a project member. I think even people who have worked with a developer might not know how. Or do mentors routinely explain/offer this if not asked explicitly for info?
I'm not that worried about that. Inkscape's actually fairly liberal with commit access so most open source developers needing commit access are used to needing to engage directly with the community.
That said, improving the docs to this effect would be nice, as I mentioned before. Feel free to add mention where you think it should be.
Some day I'd like to restructure our new devel intro materials a bit better, defining our development principles and so on, and if no one gets around to it before then I'll do another take at the commit access request directions.
Meanwhile, just keep an eye out for new folks that are actively contributing and might make good candidates for commit access and give them a personal invite. (This is probably a far friendlier and better way to bring in new devs than a button, anyway.)
Btw. the 'Request access' button is still there at https://gitlab.com/inkscape/inkscape
Thanks, I've fixed that. Looks like the top-level settings don't get inherited. We should probably move the core codebases into an Inkscape Devels subteam, and I think that may let us standardize the settings for the code repos. I'll have to think on this.
(the Inkscape group is where it is disabled now)
I've updated the projects to conform. One thing I'm uncertain about is from the description it says that this increases certain restrictions on anonymous users which may or may not be what we want. If access to anything seems to have gotten more restrictive in a bad way, let me know and I'll make adjustments.
Thanks again for reviewing this change and providing feedback. And like I mentioned, if anyone spots any serious issues with it going forward let me know and we can re-evaluate.
Bryce
Maren
Am 14.01.2018 um 05:22 schrieb Bryce Harrington:
On Sun, Jan 14, 2018 at 04:39:17AM +0100, Maren Hachmann wrote:
Could someone add a link to the info about how to join/participate to the README?
After following a detour via 'CONTRIBUTING', which would be a symlink locally, but just had a path printed inside on gitlab, I found a description here: https://gitlab.com/inkscape/inkscape/blob/master/doc/HACKING.tx t
I think that file also needs an update, telling users *how* to 'request access' now that the option via button is closed.
(what would have been the issue with just declining any non- contributor join requests? Not being able to add an explanatory note? Perhaps make this a gitlab feature request?)
Right, there is no explanation included in the requests. So there's not an easy way to tell if someone has contributed patches, whether they've been accepted, or etc. I suspect no one getting these notices knows what to do with them, so they've been just piling up; I sometimes do some sleuthing around to see if the individual has done anything with Inkscape, but it's time consuming to chase down their contribution history from scratch. The only practical way that applying works is if the applicant has been working with a developer and that developer knows they're applying for access -- in which case the developer can just add them directly, no need for the applicant to also click the button.
We had a similar problem with Launchpad, although there it had a feedback form to send the applicant an email directing them as to what they'd need to do. Also, in LP it was a bit fewer clicks to identify what they did for Inkscape, although it was still ambiguous if they'd gone through the proper process.
You are right that this could use better documentation. The HACKING file is a good start.
In general, I think most people who need commit access will be hooking in enough with the project and the rest of the developers that someone will help them get it, without needing a lot of structure. (If they're not hooked in to that level, well might not be a good candidate for giving commit rights anyway...) So I think for now, just having people ask on the inkscape-devel@ list or IRC for commit access is going to be sufficient, basically similar to how we handle wiki access.
I don't know if it is worth bothering asking for our process as a gitlab feature request, as we may be kind of unique with this. In any case I suspect it's not that hard for us to implement some web UI ourselves to accomplish the same goal, if it really bothers us.
Blue sky, maybe someday we could have some sort of unified membership access request form, to request wiki access, commit access, travel sponsorship, et al. And a corresponding administrative side page to review/comment/approve applications. It would be nice if that app had a way to programmatically tell if the user had fulfilled whatever requirements are set for access (i.e. the 2-patch rule, length of time in the project, etc.) If anyone wishes to work on such a web form, I can share further ideas, but I think we can handle things manually for the time being.
Bryce
Maren
Am 14.01.2018 um 03:29 schrieb Bryce Harrington:
I've proceeded ahead and made this config change to gitlab. Let me know if anyone spots any issues with this change.
Bryce
On Sat, Jan 13, 2018 at 09:10:59AM -0800, Bryce Harrington wrote:
On Sat, Jan 13, 2018 at 09:32:03AM +0100, Marc Jeanmougin wrote: > No objection from me, sounds nice (I did not know we > could remove the > button^^); what I tried to do at some point was to give > "Guest" role to > those users (which does not grant any right)
I also wondered about establishing an Inkscape Users subgroup that people could voluntarily add themselves to. (This might be worth doing regardless, particularly if we have some utility for it beyond just affiliation.)
Bryce
> On 01/13/2018 06:28 AM, Bryce Harrington wrote: > > There's a setting "Allow users to request access" on > > our Inkscape main > > group (https://gitlab.com/inkscape).%C2%A0%C2%A0I%27d like to > > switch it to 'off'. > > Are there any objections if I did this? > > > > This setting adds a button to our website for logged in > > users to push to > > send an email to our admins asking for membership to > > the inkscape main > > group. The effect of this gives them commit access on > > the inkscape repo > > (and I suspect maybe other git repos in subgroups; I'm > > not sure how the > > permissions propagate.) > > > > This was useful initially when everyone was needing > > gitlab access, but I > > think all the existing committers that want it have > > it. These days the > > requests we're getting are mostly from people with no > > registered > > activity related to Inkscape; we've been getting a > > handful of these > > invalid requests each month. Maybe they're clicking it > > on accident, or > > thinking that it's an affiliation mark, and not > > realizing that it gives > > full commit rights if granted. > > > > Turning it off simply removes the button, it wouldn't > > mean any change to > > our existing policies regarding earning of commit > > rights - applicants > > still need to get two patches reviewed, accepted, and > > landed and then > > contact one of the administrators to request > > access. (If we want to > > make this simpler later on, maybe one day we can rig up > > a form where > > they can enter the SHAs of their two patches.) > > > > Bryce > > > > ----------------------------------------------------- > > ------------------------- > > Check out the vibrant tech community on one of the > > world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slas > > hdot > > _______________________________________________ > > Inkscape-devel mailing list > > Inkscape-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/inkscape-d > > evel > > > > ------------------------------------------------------- > ----------------------- > Check out the vibrant tech community on one of the > world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashd > ot > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-dev > el
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel