> The default for a team is "secret" which means members are not visible to
anyone, the only other option available is "closed" which means the members
are visible only to members of the organization, not the general public. I
think since it is not exposed to the general public that this should be
>
> Possibly could give maintainers team maintainer permission to help with
> that if the person they want to add is a member of the org
>
>
We usually grant Admin permissions to new teams so that they can manage
their GitHub apps & Co.
We started doing that before Maintainer permissions were
Possibly could give maintainers team maintainer permission to help with
that if the person they want to add is a member of the org
On Mon, 13 Jan 2020 at 13:37, Daniel Beck wrote:
> How do you plan to address issues in plugins whose maintainers are largely
> (or even completely) managed outside
On Mon, Jan 13, 2020 at 2:43 PM 'Gavin Mogan' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:
> I think blueocean should always be treated as the exception not the rule.
>
There are currently around 300 outside collaborators to jenkinsci
repositories (compared to 2000 members),
I think blueocean should always be treated as the exception not the rule. I
tried to do the codeowners for it and didn't realize the privacy thing.
https://github.com/jenkinsci/blueocean-plugin/blob/master/CODEOWNERS
Codeowners would be opt in, and maybe even defaulted. But not mandatory. I
think
How do you plan to address issues in plugins whose maintainers are largely
(or even completely) managed outside the repo-specific team, or with custom
teams that are largely maintained manually?
Since we grant repo admin permissions, it's easiest for maintainers to just
add new people as external
The default for a team is "secret" which means members are not visible to
anyone, the only other option available is "closed" which means the members
are visible only to members of the organization, not the general public. I
think since it is not exposed to the general public that this should be
Looks like the github-api library does not currently support setting the
`privacy` value for a team.
On Mon, Jan 13, 2020 at 5:58 AM Tim Jacomb wrote:
> The list of maintainers is already public in the repository permissions
> list,
>
> +1 for changing this
>
> I assume the API call needs to be
But the teams are not, and that could expose individuals without their consent.
> On Jan 13, 2020, at 4:58 AM, Tim Jacomb wrote:
>
>
> The list of maintainers is already public in the repository permissions list,
>
> +1 for changing this
>
> I assume the API call needs to be updated
The list of maintainers is already public in the repository permissions
list,
+1 for changing this
I assume the API call needs to be updated slightly in the IRC bot
Thanks
Tim
On Mon, 13 Jan 2020 at 12:46, Marky Jackson
wrote:
> Oleg,
> I feel that need some form of consent from maintainers.
I think this proposal sounds good. The groups are created automatically by
the bot, so its not like its a thing we are trying to hide anyway. Is there
anything we need to do in the bot to make sure these groups are public
going forward as new plugins are hosted?
On Mon, Jan 13, 2020 at 5:32 AM
Quite happy for that in the case of the plugins I maintain. My details are
in the POMs anyway.
On Mon, Jan 13, 2020 at 12:46 PM Marky Jackson
wrote:
> Oleg,
> I feel that need some form of consent from maintainers.
>
> On Jan 13, 2020, at 4:32 AM, Oleg Nenashev wrote:
>
>
> One thing here
Oleg,
I feel that need some form of consent from maintainers.
> On Jan 13, 2020, at 4:32 AM, Oleg Nenashev wrote:
>
>
> One thing here is that the most of the pluginId-developers teams are secret
> at the moment, and the teams must be public to operate properly with
> CODEOWNERS.
> I
One thing here is that the most of the *pluginId-developers* teams are
secret at the moment, and the teams must be public to operate properly with
CODEOWNERS.
I suggest to make all of them public, IMHO there is no value in hiding
teams in the open-source project (apart form unintended mention
I'd guess any plugin maintainer can just proceed and add CODEOWNERS to the
repo.
There is no need to wait for the bot if you want to start adopting the
suggestion :)
On Thursday, January 9, 2020 at 7:07:08 PM UTC+1, Gavin Mogan wrote:
>
> Sweet I was going to suggest the same thing..
>
> Lots
Sweet I was going to suggest the same thing..
Lots of plugin maintainers don't realize they are not "watching" a repo.
and I think tools like pr bot don't count you unless your listed as a
reviewer
So much +1 for me
On Thu., Jan. 9, 2020, 6:29 a.m. Oleg Nenashev,
wrote:
> Perfect, this makes
>
> Perfect, this makes the barrier to acceptance quite low, without forcing a
> change on anyone.
>
Yes, I do not think we are in position to enforce the process at the
moment. Historically Jenkins project gives a lot of freedom to plugin
maintainers to define how they operate, and IMHO it
On Thu, Jan 9, 2020 at 8:05 AM Oleg Nenashev wrote:
> We add CODEOWNERS template to plugin archetypes
Yes, though we need to do JENKINS-58557 first.
> We submit pull requests […]
> Each plugin maintainer or maintainer team will decide on their own whether
> they accept the process or not.
+! from me. I like that idea very much.
On Thu, Jan 9, 2020 at 6:05 AM Oleg Nenashev wrote:
> Hi all,
>
> I propose to improve the code review process across the Jenkins GitHub
> organization. TL;DR: Let's introduce CODEOWNERS in repositories and
> automatically request reviews from maintainer
Hi all,
I propose to improve the code review process across the Jenkins GitHub
organization. TL;DR: Let's introduce CODEOWNERS in repositories and
automatically request reviews from maintainer teams.
*Motivation:* In a number of plugins we have issues with pull requests
which do not get timely
20 matches
Mail list logo
