Re: [GitLab] Projects moved, general comments, tips of the week, question of the week

[Carlos Soriano]

> I apologize, if I sounded inappropriate earlier.

No worries, it was fine. I probably wasn't clear in the past what people
need to do to discuss these priorities and it's a very valid question.

Cheers

Carlos Soriano
GNOME Board of Directors

On 28 February 2018 at 17:38, Milan Crha  wrote:

> On Wed, 2018-02-28 at 15:39 +0100, Carlos Soriano wrote:
> > Hope this was useful and clarified any doubt you might have, it
> > certainly took some time to write.
>
> Hi,
> thanks for the explanation. It was definitely useful for me. I agree
> it's not simple to evaluate the priority. The "once per two months" can
> change once everyone will start use the tool, but that's only another
> nitpick from my side.
>
> Again, thanks a lot for sharing all of that. I apologize, if I sounded
> inappropriate earlier.
> Thanks and bye,
> Milan
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Projects moved, general comments, tips of the week, question of the week

[Milan Crha]

On Wed, 2018-02-28 at 15:39 +0100, Carlos Soriano wrote:
> Hope this was useful and clarified any doubt you might have, it
> certainly took some time to write.

Hi,
thanks for the explanation. It was definitely useful for me. I agree
it's not simple to evaluate the priority. The "once per two months" can
change once everyone will start use the tool, but that's only another
nitpick from my side.

Again, thanks a lot for sharing all of that. I apologize, if I sounded
inappropriate earlier.
Thanks and bye,
Milan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Projects moved, general comments, tips of the week, question of the week

[Carlos Soriano]

PD: The email is long, but I hope it clarifies how I work about the GitLab
stuff to anyone that might be in doubt about the evaluation process and how
I set priorities to issues that impact GNOME.

> Hmm, applying the same logic you can open a GNOME's gitlab issue for
"tips of the week" and update it, instead of sending the message here,
because you are addressing the same group of people, no? :)

How...do you think I track them? :) [spoiler]
https://gitlab.gnome.org/Infrastructure/GitLab/issues/101 [/spoiler]

> But seriously, my main point is that not every developer follows issues
filled in GNOME infrastructure gitlab issue tracker, thus even it's a
public place, it doesn't reach the group of people whose the decision
will influence the most.

So what do you propose? We are precisely doing this right now... discussing
an issue you consider important.

Don't you think doing something else will add even more noise to the
already noisy GitLab topic that we can barely achieve people to get engaged
and involved with? Don't you see that what I'm trying to do with all this
stuff is to make sure noise is low and focus that people participate in the
real important topics?

I believe you are proposing just what we already do, the 'question of the
week' is intended to give focus onto a single issue per week, so at least I
can tell the community 'look, this is important and impacts all of us in a
higher level, please participate, I promise I'll keep request for feedback
low'.

Regarding individual items as priorities, as I mentioned I evaluate the big
picture and the feedback from everyone, if you don't follow all the issues
and feedback about this stuff that's fine, that's why I do it to take
everything into account to create that list... if you are particularly
interested into one, feel free to send an email this mailing list and say
"what you all think to make this higher priority?" If you get people
interested, and after explaining the big picture for that particular one
you all agree this deserves higher priority, I will just increase it, I
don't have any personal preference or interest while doing these GitLab
tasks.

If this didn't happen much until now, it's because I believe people here
are happy with how this is being handled and the priorities given to each
issue, always keeping in mind these evaluations are done with a GNOME wide
mindset, not with an individual mindset, and also keeping in mind that we
should avoid making it a voting contest, as our folks at Mozilla can tell
too  when they were
evaluating the switch to Phabricator.

> It also surprised me that the fresh "Allow to disable group mentions -
#43686" is considered Minor. It's not a deal breaker, of course, but it
has some consequences too.

Ok I'll explain my process of evaluation for priorities. Usually I do:
- Evaluate the context: how the issue was done, what frequency, how many
projects, how important are the projects and how many people it affects...
- Evaluate the consequences: What a developer would feel and for how long,
for how many times this affects their performance, how much it affects
their performance, how much it impacts the willing to use the tool, if the
issue was present before in BZ...
- Evaluate solutions: how much the solution impacts people affected, how
fast can the admins be to apply the solution, how effective is it.
- Evaluate if an upstream solution is possible and if it fits upstream
vision: There is no point to propose to GitLab to do something completely
against their vision, so I need to eavluate this and scope the issues as
much as possible. This is all our meetings with them, discussions how we
can make fit both GNOME needs and GitLab needs, and if there is some
possible trade off, then it's viable to add it to the list.

Now, let's go to your issue #43686:
- How many people does it affect? It affects all GNOME. This makes it to
the list directly, there is no doubt.
- Now, how frequent is it? Well, once per two months.
- What are the consequences? Developers get an email, get angry for 2
minutes
- What are the solutions? Admins go and stop the thing locking the issue
and everyone moves on.
- How the dev performance was impacted? It might be a lot, but it's only
for two minutes. It doesn't prevent you to work further or to stop using
the tool.
- Is it a big impact in the whole GNOME that affects their workflow in a
considerate way? I don't think so.
- Evaluate if an upstream solution is possible and if it fits upstream
vision: Yes, they disabled @all recently for non-project members
.

Now let's evaluate the issue just a bit above this one, an "internal error
when editing a issue description with task list":
- How many people does it affect? Potentially everyone, but in reality
one/two people per week.
- What are the consequences? Developer cannot longer edit an issue or put a
task as completed. This could 

Re: [GitLab] Projects moved, general comments, tips of the week, question of the week

[Andre Klapper]

On Wed, 2018-02-28 at 14:06 +0100, Milan Crha wrote:
> But seriously, my main point is that not every developer follows issues
> filled in GNOME infrastructure gitlab issue tracker, thus even it's a
> public place, it doesn't reach the group of people whose the decision
> will influence the most.

What's the difference to "not everybody follows activity in Bugzilla /
IRC / mailing lists" and how's that a new problem specific to GitLab?

I'm afraid I still don't understand the problem.

andre
-- 
Andre Klapper  |  ak...@gmx.net
http://blogs.gnome.org/aklapper/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Projects moved, general comments, tips of the week, question of the week

[Milan Crha]

Hi,

On Wed, 2018-02-28 at 13:21 +0100, Carlos Soriano wrote:
> There is no subset of people in GNOME's GitLab issue tracker, you all
> can comment there, that's why it's public :)

Hmm, applying the same logic you can open a GNOME's gitlab issue for
"tips of the week" and update it, instead of sending the message here,
because you are addressing the same group of people, no? :)

But seriously, my main point is that not every developer follows issues
filled in GNOME infrastructure gitlab issue tracker, thus even it's a
public place, it doesn't reach the group of people whose the decision
will influence the most.

It also surprised me that the fresh "Allow to disable group mentions -
#43686" is considered Minor. It's not a deal breaker, of course, but it
has some consequences too.

By the way, how does that
https://gitlab.com/gitlab-org/gitlab-ce/issues/43566 work? Once the
"High" section is done all left GNOME projects will be migrated to
GNOME's gitlab instance and bugzilla will be switched to read-only
mode, or? I'm just wondering.
Thanks and bye,
Milan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Projects moved, general comments, tips of the week, question of the week

[Carlos Soriano]

Hey Milan,

This is what we do already... no? We discuss it in public and evaluate
what's important, then I try to take all this stuff into account, look at
the big picture, and come up with some specific list to GitLab upstream.

There is no subset of people in GNOME's GitLab issue tracker, you all can
comment there, that's why it's public :)

Cheers

On 28 February 2018 at 13:03, Milan Crha  wrote:

> On Fri, 2018-02-23 at 21:40 +0100, Carlos Soriano wrote:
> > If you have some issue or feature request that might impact GNOME as
> > a whole and you think it's important for GNOME create an issue in our
> > infra project and we can discuss if we should add it as priority for
> > GNOME.
>
> Hi,
> I'm wondering, would it be better to have the potential issues
> discussed more in public, like here, thus the GNOME
> community/developers can decide which issues are important to them and
> which not, instead of keeping the last word on a small subset of people
> in some group in the GNOME's GitLab issue tracker? I do not expect
> anyone periodically check whether any interesting topic wasn't added
> there and eventually rise his/her voice there. And as always, different
> people have different opinions, different priorities, different point
> of view, different...
> Thanks and bye,
> Milan
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Projects moved, general comments, tips of the week, question of the week

[Milan Crha]

On Fri, 2018-02-23 at 21:40 +0100, Carlos Soriano wrote:
> If you have some issue or feature request that might impact GNOME as
> a whole and you think it's important for GNOME create an issue in our
> infra project and we can discuss if we should add it as priority for
> GNOME.

Hi,
I'm wondering, would it be better to have the potential issues
discussed more in public, like here, thus the GNOME
community/developers can decide which issues are important to them and
which not, instead of keeping the last word on a small subset of people
in some group in the GNOME's GitLab issue tracker? I do not expect
anyone periodically check whether any interesting topic wasn't added
there and eventually rise his/her voice there. And as always, different
people have different opinions, different priorities, different point
of view, different...
Thanks and bye,
Milan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

[GitLab] Projects moved, general comments, tips of the week, question of the week

[Carlos Soriano]

Our migration is going faster that I have planned. We reached our second
milestone today, the most core-ish platform-ish modules asked for a
migration and are now migrated. So allow me to do two claps 

*Projects migrated today*

- gtk  (no bugs yet)
- glib  (no bugs yet)
- gobject-introspection

- gnome-control-center 
(no bugs yet)
- gnome-settings-daemon
 (no bugs yet)
- gxml 

** for those without bug migrations yet, consult their respective
maintainers for more info on their plans.*



*General comments for maintainers*For those maintainers that migrated
switch the permissions of the master branch to "masters and developers" in
"settings → general → repository → protected branches → master", since
there is no API for that I cannot do it when migrating, but we want to
allow all developers to be able to push to the master branch.

For those that want to migrate, remember to have your doap files updated
since only maintainers will be able to change settings in the project.



*Tips- Modifying multiple MR and issues at the same time: *In the issues or
MR view, click the "edit issues/MR" button on the top right and select the
issues/MR you want to batch modify. You can apply labels, close them,
subscribe to them, etc.

*- Automatically make discussions resolved when the same line is updated:*
"Settings→General → Merge request settings → Automatically resolve merge
request diff discussions when they become outdated". This is something that
probably

* most of you want.- Show more code context in a review: *In a diff, click
the three dots on the corners. Example shown in this pic (with my
above-average GIMP skills):


*​*


*Question of the week*GitLab support issues templates, some text in
markdown that will be shown for reporters when creating a new issue.
Multiple issues template are supported, reporters can select them in a
dropdown. The question is,

* what issue template should we use for when reporters create an issue?*Ideally
we would have a common template and maintainers will tweak it if necessary
for their projects. Please comment on the issue
 your ideas an
thoughts, there is currently no proposal.

Enjoy and welcome to 2018.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list