Gerrit now automatically adds reviewers

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

Re: [Engineering] Gerrit now automatically adds reviewers

Thiemo Kreuz
> Fundamentally broken sounds like a bit of a stretch.

A process that annoys people based on nothing but the fact that they
happened to be the last one touching a file *is* fundamentally broken.
This is not how anyone should look for reviewers, neither manually nor
automatically.

Here is a thought experiment: We could send review requests to the
*least* active users that are still around, but *never* touched a
file. The positive effects of such an approach include:
* More people get familiar with the code.
* Knowledge gets spread more evenly.
* Bottlenecks and bus factors get reduced.
* These people probably have more time.
* Review requests are spread more evenly.
* Workload is spread more evenly.

Still sounds like a bad idea? Sure, because it is. Now tell me: How is
it more clever to do the *opposite* and dump review requests on people
that have to much workload already?

At this point I don't care any more if we are talking about a fully
automated process or a suggest button. Both are targeting the wrong
people.

> it was probably working quite well for our less-trafficked repositories.

What is the difference between being the last one fixing a typo in a
low-traffic vs. high-traffic repository? In both cases it's the wrong
person.

Thiemo

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Engineering] Gerrit now automatically adds reviewers

Chad
On Tue, Jan 22, 2019 at 4:05 AM Thiemo Kreuz <[hidden email]>
wrote:

> > Fundamentally broken sounds like a bit of a stretch.
>
> A process that annoys people based on nothing but the fact that they
> happened to be the last one touching a file *is* fundamentally broken.
> This is not how anyone should look for reviewers, neither manually nor
> automatically.


It isn't? I figured "people who have worked on this code before" is an
excellent metric by which to find people to review your code. It's certainly
who I'd look to help me if I didn't just _know_ who to ask.


>
>
Here is a thought experiment: We could send review requests to the

> *least* active users that are still around, but *never* touched a
> file. The positive effects of such an approach include:
> * More people get familiar with the code.
> * Knowledge gets spread more evenly.
> * Bottlenecks and bus factors get reduced.
> * These people probably have more time.
> * Review requests are spread more evenly.
> * Workload is spread more evenly.
>
> Still sounds like a bad idea? Sure, because it is.


Dumb straw man.


> Now tell me: How is
> it more clever to do the *opposite* and dump review requests on people
> that have to much workload already?
>

Who said these people have too much workload? Just because they've
made a commit before? The blame attribution has zero insight into how
busy someone is.


> At this point I don't care any more if we are talking about a fully
> automated process or a suggest button. Both are targeting the wrong
> people.


>
> it was probably working quite well for our less-trafficked repositories.
>
> What is the difference between being the last one fixing a typo in a
> low-traffic vs. high-traffic repository? In both cases it's the wrong
> person.
>

If it's a low-traffic repository there's likely to be fewer overall
contributors.
Fewer contributors increases the likelihood of people being qualified to
review--whereas a high-traffic repo is more likely to have drive-by
contributor less capable.

And if it's just one-line typofixing it'd be ideal to exclude those from the
blame list--but we can't possibly know what was a one-line typofix and
what was a one line that saved us 50% of execution time on all pages.
At least not programmatically.

Honestly, if you think "people who've edited the code in the past" are a
poor
person to ask for review then you do not understand how code review works.

-Chad
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Engineering] Gerrit now automatically adds reviewers

Wikipedia Developers mailing list
In reply to this post by Thiemo Kreuz
 What your saying is making me think I’m wasting my time on improving this extension.
Also other users that have spoken to me have thought this extension is great but could do with improvements which I am doing. We need to think of new users and how to improve there experence. The task was opened for a long while yet no one commented on it.
I agree with legoktm feedback.
“A process that annoys people based on nothing but the fact that theyhappened to be the last one touching a file *is* fundamentally broken.”
yes hence why I’ve been making improvements by adding a button which is better then nothing right?
As chad mentions it has no idea what is a typo fix compared to other things as it’s not A.I.

    On Tuesday, 22 January 2019, 12:05:24 GMT, Thiemo Kreuz <[hidden email]> wrote:  
 
 > Fundamentally broken sounds like a bit of a stretch.

A process that annoys people based on nothing but the fact that they
happened to be the last one touching a file *is* fundamentally broken.
This is not how anyone should look for reviewers, neither manually nor
automatically.

Here is a thought experiment: We could send review requests to the
*least* active users that are still around, but *never* touched a
file. The positive effects of such an approach include:
* More people get familiar with the code.
* Knowledge gets spread more evenly.
* Bottlenecks and bus factors get reduced.
* These people probably have more time.
* Review requests are spread more evenly.
* Workload is spread more evenly.

Still sounds like a bad idea? Sure, because it is. Now tell me: How is
it more clever to do the *opposite* and dump review requests on people
that have to much workload already?

At this point I don't care any more if we are talking about a fully
automated process or a suggest button. Both are targeting the wrong
people.

> it was probably working quite well for our less-trafficked repositories.

What is the difference between being the last one fixing a typo in a
low-traffic vs. high-traffic repository? In both cases it's the wrong
person.

Thiemo

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l 
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Engineering] Gerrit now automatically adds reviewers

Lucas Werkmeister
In reply to this post by Chad
Am Di., 22. Jan. 2019 um 13:25 Uhr schrieb Chad <[hidden email]>:

> Dumb straw man.
>

can we avoid this tone? thanks

Who said these people have too much workload?


Um, Thiemo himself has said this? Are you going to tell him that he’s wrong
about his own workload?

The blame attribution has zero insight into how
> busy someone is.
>

Correct, which is why it’s a bad idea to let it run loose and add people
who are already busy enough as reviewers.


> If it's a low-traffic repository there's likely to be fewer overall
> contributors.
> Fewer contributors increases the likelihood of people being qualified to
> review--whereas a high-traffic repo is more likely to have drive-by
> contributor less capable.
>

Well, many drive-by contributions are tree-wide: they are applied to a
large set of repositories collectively, e. g. all Wikimedia-deployed
extensions or even all repositories. If a repository has generally low
traffic, then these tree-wide drive-by contributions will make up a larger
ratio of its commits than in repositories with more repository-specific
commits.

I’m not sure if I phrased this well, but if repository A has 1000 specific
commits and 10 drive-by commits, and repository B has 20 specific commits
and the same 10 drive-by commits, then the drive-by commits will be ⅓ of
all commits in repository B but less than .1% in repository A.


> And if it's just one-line typofixing it'd be ideal to exclude those from
> the
> blame list--but we can't possibly know what was a one-line typofix and
> what was a one line that saved us 50% of execution time on all pages.
> At least not programmatically.
>

True to some extent, but then we should err on the side of not adding the
reviewer, no? Otherwise we run the risk of overwhelming them with changes
they’re not even qualified to review, even if they had the time.


> Honestly, if you think "people who've edited the code in the past" are a
> poor
> person to ask for review then you do not understand how code review works.
>

Suggesting that Thiemo doesn’t understand how code review works is… bold,
in my opinion, let’s put it that way. May I point out that he’s one of the
top +2ers across all MediaWiki extensions
<https://lists.wikimedia.org/pipermail/wikitech-l/2019-January/091340.html>?

Cheers,
Lucas


--
Lucas Werkmeister
Full Stack Developer

Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30 219 158 26-0
https://wikimedia.de

Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
https://spenden.wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Engineering] Gerrit now automatically adds reviewers

Physikerwelt
I suggest discussing the implementation details on phabricator.
Moreover, I second Lucas point on the tone.
physikerwelt
https://www.mediawiki.org/wiki/Code_of_Conduct

physikerwelt
https://www.mediawiki.org/wiki/Code_of_Conduct

On Tue, Jan 22, 2019 at 1:43 PM Lucas Werkmeister
<[hidden email]> wrote:

>
> Am Di., 22. Jan. 2019 um 13:25 Uhr schrieb Chad <[hidden email]>:
>
> > Dumb straw man.
> >
>
> can we avoid this tone? thanks
>
> Who said these people have too much workload?
>
>
> Um, Thiemo himself has said this? Are you going to tell him that he’s wrong
> about his own workload?
>
> The blame attribution has zero insight into how
> > busy someone is.
> >
>
> Correct, which is why it’s a bad idea to let it run loose and add people
> who are already busy enough as reviewers.
>
>
> > If it's a low-traffic repository there's likely to be fewer overall
> > contributors.
> > Fewer contributors increases the likelihood of people being qualified to
> > review--whereas a high-traffic repo is more likely to have drive-by
> > contributor less capable.
> >
>
> Well, many drive-by contributions are tree-wide: they are applied to a
> large set of repositories collectively, e. g. all Wikimedia-deployed
> extensions or even all repositories. If a repository has generally low
> traffic, then these tree-wide drive-by contributions will make up a larger
> ratio of its commits than in repositories with more repository-specific
> commits.
>
> I’m not sure if I phrased this well, but if repository A has 1000 specific
> commits and 10 drive-by commits, and repository B has 20 specific commits
> and the same 10 drive-by commits, then the drive-by commits will be ⅓ of
> all commits in repository B but less than .1% in repository A.
>
>
> > And if it's just one-line typofixing it'd be ideal to exclude those from
> > the
> > blame list--but we can't possibly know what was a one-line typofix and
> > what was a one line that saved us 50% of execution time on all pages.
> > At least not programmatically.
> >
>
> True to some extent, but then we should err on the side of not adding the
> reviewer, no? Otherwise we run the risk of overwhelming them with changes
> they’re not even qualified to review, even if they had the time.
>
>
> > Honestly, if you think "people who've edited the code in the past" are a
> > poor
> > person to ask for review then you do not understand how code review works.
> >
>
> Suggesting that Thiemo doesn’t understand how code review works is… bold,
> in my opinion, let’s put it that way. May I point out that he’s one of the
> top +2ers across all MediaWiki extensions
> <https://lists.wikimedia.org/pipermail/wikitech-l/2019-January/091340.html>?
>
> Cheers,
> Lucas
>
>
> --
> Lucas Werkmeister
> Full Stack Developer
>
> Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
> Phone: +49 (0)30 219 158 26-0
> https://wikimedia.de
>
> Imagine a world in which every single human being can freely share in the
> sum of all knowledge. Help us to achieve our vision!
> https://spenden.wikimedia.de
>
> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
> der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
> Körperschaften I Berlin, Steuernummer 27/029/42207.
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Engineering] Gerrit now automatically adds reviewers

Thiemo Kreuz
In reply to this post by Chad
> […] "people who have worked on this code before" is an excellent metric by which to find people to review your code.

Sure. But this is neither what I wrote, nor what the plugin does, nor
what can be done programmatically in the first place, as you
conveniently pointed out yourself:

> […] we can't possibly know what was a one-line typofix and what was a one line that saved us 50% of execution time on all pages. At least not programmatically.

Kind regards
Thiemo

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Engineering] Gerrit now automatically adds reviewers

Niharika Kohli-2
In reply to this post by Wikipedia Developers mailing list
On Tue, Jan 22, 2019 at 6:12 PM Paladox via Wikitech-l <
[hidden email]> wrote:

>  What your saying is making me think I’m wasting my time on improving this
> extension.
> Also other users that have spoken to me have thought this extension is
> great but could do with improvements which I am doing. We need to think of
> new users and how to improve there experence. The task was opened for a
> long while yet no one commented on it.
> I agree with legoktm feedback.
> “A process that annoys people based on nothing but the fact that
> theyhappened to be the last one touching a file *is* fundamentally broken.”
> yes hence why I’ve been making improvements by adding a button which is
> better then nothing right?
> As chad mentions it has no idea what is a typo fix compared to other
> things as it’s not A.I.
>

Thanks for working on this, Paladox. I think this can be a really useful
feature for newcomers and experienced developers alike, if implemented
well. I look forward to seeing it in action.


>     On Tuesday, 22 January 2019, 12:05:24 GMT, Thiemo Kreuz <
> [hidden email]> wrote:
>
>  > Fundamentally broken sounds like a bit of a stretch.
>
> A process that annoys people based on nothing but the fact that they
> happened to be the last one touching a file *is* fundamentally broken.
> This is not how anyone should look for reviewers, neither manually nor
> automatically.
>
> Here is a thought experiment: We could send review requests to the
> *least* active users that are still around, but *never* touched a
> file. The positive effects of such an approach include:
> * More people get familiar with the code.
> * Knowledge gets spread more evenly.
> * Bottlenecks and bus factors get reduced.
> * These people probably have more time.
> * Review requests are spread more evenly.
> * Workload is spread more evenly.
>
> Still sounds like a bad idea? Sure, because it is. Now tell me: How is
> it more clever to do the *opposite* and dump review requests on people
> that have to much workload already?
>
> At this point I don't care any more if we are talking about a fully
> automated process or a suggest button. Both are targeting the wrong
> people.
>
> > it was probably working quite well for our less-trafficked repositories.
>
> What is the difference between being the last one fixing a typo in a
> low-traffic vs. high-traffic repository? In both cases it's the wrong
> person.
>
> Thiemo
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
Niharika
Product Manager
Community Tech
Wikimedia Foundation
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Engineering] Gerrit now automatically adds reviewers

Cormac Parle
+1 to Niharika - the initial iteration caused some inconvenience, but I expect subsequent iterations to be useful. Thank you Paladox!





> On 22 Jan 2019, at 13:09, Niharika Kohli <[hidden email]> wrote:
>
> On Tue, Jan 22, 2019 at 6:12 PM Paladox via Wikitech-l <
> [hidden email]> wrote:
>
>> What your saying is making me think I’m wasting my time on improving this
>> extension.
>> Also other users that have spoken to me have thought this extension is
>> great but could do with improvements which I am doing. We need to think of
>> new users and how to improve there experence. The task was opened for a
>> long while yet no one commented on it.
>> I agree with legoktm feedback.
>> “A process that annoys people based on nothing but the fact that
>> theyhappened to be the last one touching a file *is* fundamentally broken.”
>> yes hence why I’ve been making improvements by adding a button which is
>> better then nothing right?
>> As chad mentions it has no idea what is a typo fix compared to other
>> things as it’s not A.I.
>>
>
> Thanks for working on this, Paladox. I think this can be a really useful
> feature for newcomers and experienced developers alike, if implemented
> well. I look forward to seeing it in action.
>
>
>>    On Tuesday, 22 January 2019, 12:05:24 GMT, Thiemo Kreuz <
>> [hidden email]> wrote:
>>
>>> Fundamentally broken sounds like a bit of a stretch.
>>
>> A process that annoys people based on nothing but the fact that they
>> happened to be the last one touching a file *is* fundamentally broken.
>> This is not how anyone should look for reviewers, neither manually nor
>> automatically.
>>
>> Here is a thought experiment: We could send review requests to the
>> *least* active users that are still around, but *never* touched a
>> file. The positive effects of such an approach include:
>> * More people get familiar with the code.
>> * Knowledge gets spread more evenly.
>> * Bottlenecks and bus factors get reduced.
>> * These people probably have more time.
>> * Review requests are spread more evenly.
>> * Workload is spread more evenly.
>>
>> Still sounds like a bad idea? Sure, because it is. Now tell me: How is
>> it more clever to do the *opposite* and dump review requests on people
>> that have to much workload already?
>>
>> At this point I don't care any more if we are talking about a fully
>> automated process or a suggest button. Both are targeting the wrong
>> people.
>>
>>> it was probably working quite well for our less-trafficked repositories.
>>
>> What is the difference between being the last one fixing a typo in a
>> low-traffic vs. high-traffic repository? In both cases it's the wrong
>> person.
>>
>> Thiemo
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> _______________________________________________
>> Wikitech-l mailing list
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
> --
> Niharika
> Product Manager
> Community Tech
> Wikimedia Foundation
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Engineering] Gerrit now automatically adds reviewers

Antoine Musso-3
In reply to this post by Pine W
On 18/01/2019 23:12, Pine W wrote:

> I'm glad that this problematic change to communications was reverted.
>
> I would like to suggest that this is the type of change that, when being
> planned, should get a design review from a third party before coding
> starts, should go through at least one RFC before coding starts, and be
> widely communicated before coding starts and again a week or two before
> deployment. Involving TechCom might also be appropriate. It appears that
> none of those happened here. In terms of process this situation looks to me
> like it's inexcusable.
>
> In the English Wikipedia community, doing something like this would have a
> reasonable likelihood of costing an administrator their tools, and I hope
> that a similar degree of accountability is enforced in the engineering
> community. In particular, I expect engineering supervisors to follow
> established technical processes for changes that impact others' workflows,
> and if they decide to skip those processes without a compelling reason
> (such as a site stability problem) then I hope that they will be held
> accountable. Again, from my perspective, the failure to follow process here
> is inexcusable.
>
> Pine

Hello Pine

We had the Gerrit reviewers-by-blame installed a while ago although it
was not functional. Tyler, Gergo and I have been talking about that idea
for quite a while and felt like it was a good idea to get patches reviewed.

On a quick though, if one authored some code, most probably that person
knows the code and thus would qualify as a reviewers. For the few code I
wrote from scratch, I am certainly interested in being added automatically.

Anyway, we went with upgrading the Gerrit plugin. I even wrote a blog
post to explain a bit of the feature and other ways to find reviewers:
https://phabricator.wikimedia.org/phame/post/view/139/

I don't write blogs that often. If I do it is because I am excited about
some feature which I firmly believe to be a general improvement.  I have
been naive?  Yes surely.  Did we miss evaluating potential side effects?
  For sure.

Then one as to take in perspective the cost of trying and reverting
versus spending ages and months on a project only to dish it out because
that is not what the customer wanted.  I, and several, choose the first
path: quick cheap experiment with limited casualties. A benefit is that
this thread gave a lot of exposure to the feature and gathered a lot of
constructive feedback.  One can then easily conclude that the plugin is
not smart enough and fails to spot the proper reviewers.

The plugin does not add reviewers any more (it defaults to add 0
reviewers), and I guess we will just uninstall it entirely.


As for new features for Gerrit or Phabricator or CI. There is no due
process established. We just f***ing do it, given we promptly rollback
when we screw up which is thankfully rather rare.  Else we iterate and
refine the feature until it is deemed stable.

That is how we maintain our infrastructure, not by having four hours
meetings week after weeks with no deployment in between, not by having
cross teams agreement, nor five level of political hierarchy drama.  We
certainly had a few outages here and there, but given the very few
people working on those parts and the number of modifications we do on a
weekly basis, I think it is overall rather stable.


I am not willing to start a flame war, but I do not think the English
Wikipedia community is a good example of an healthy one. The huge amount
of process and policies makes it a challenge to have edits retained, it
is partly what made me stop editing entirely.


In short, Pine, please assume good faith 8-]


--
Antoine "hashar" Musso
{^-^}


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: [Engineering] Gerrit now automatically adds reviewers

Tyler Cipriani
In reply to this post by Wikipedia Developers mailing list
Hi all!

This plugin has been removed entirely from Wikimedia Gerrit[0]. I know
of no one who intended to experiment with the plugin in its current form
so it is now removed.

I have created a task to track suggestions for this plugin's
improvement[1]. This task's scope is to track suggestions for
improvements to the reviewers-by-blame plugin so they are not lost in
this thread. Implementation details about individual suggestions should
(likely) become seperate tasks.

Any discussion about what is needed to re-enable this plugin for
Wikimedia's Gerrit is a different discussion for another task and time.
We won't re-enable this plugin without notice or without further
discussion.

>On 19-01-21 18:20:13, Paladox via Wikitech-l wrote:
>FYI i have a working prototype working ("Suggest Reviewer") button.
>
>>On Monday, 21 January 2019, 16:32:35 GMT, Paladox via Wikitech-l <[hidden email]> wrote:
>>
>>I’m currently working on addressing all the feedback as fast as I can.
>>I honestly think this extension is great especially for new users, who
>>do not know they need reviewers or who would review there change.
>>Granted this extension has some problems hence why feature requests
>>were filed against the extension.
+1 to what Niharika and other have said: thank you for all your work on
Gerrit, Paladox!

You have made maintaining and keeping Gerrit secure easier for me
personally.

Thanks all for your thoughts on this thread, and thank you in advance for
ensuring the task for suggestions for improvement is accurate.

-- Tyler

[0]. <https://tools.wmflabs.org/sal/log/AWh2D-odA1BDhGjCUFA8>
[1]. <https://phabricator.wikimedia.org/T214397>

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Re: [Engineering] Gerrit now automatically adds reviewers

Amir Sarabadani-2
Hello,
This is Amir, Chair of the code of conduct committee, talking on behalf of
it.

We received several reports about the discussion happening here which we
will handle and act accordingly but in the mean time, we would like to
remind everyone to follow CoC [1] and be more mindful of what they write.
Think with yourself when writing an email "Is this email moving the
discussion forward or it's just criticizing non-constructively?" If the
answer is the latter, please refrain from sending it. Insisting on sending
nonconstructive angry emails will get you banned temporarily or permanently
from this mailing list.

[1]: https://www.mediawiki.org/wiki/Code_of_Conduct

Regards,
Code of Conduct Committee, MediaWiki.

On Tue, Jan 22, 2019 at 4:36 PM Tyler Cipriani <[hidden email]>
wrote:

> Hi all!
>
> This plugin has been removed entirely from Wikimedia Gerrit[0]. I know
> of no one who intended to experiment with the plugin in its current form
> so it is now removed.
>
> I have created a task to track suggestions for this plugin's
> improvement[1]. This task's scope is to track suggestions for
> improvements to the reviewers-by-blame plugin so they are not lost in
> this thread. Implementation details about individual suggestions should
> (likely) become seperate tasks.
>
> Any discussion about what is needed to re-enable this plugin for
> Wikimedia's Gerrit is a different discussion for another task and time.
> We won't re-enable this plugin without notice or without further
> discussion.
>
> >On 19-01-21 18:20:13, Paladox via Wikitech-l wrote:
> >FYI i have a working prototype working ("Suggest Reviewer") button.
> >
> >>On Monday, 21 January 2019, 16:32:35 GMT, Paladox via Wikitech-l <
> [hidden email]> wrote:
> >>
> >>I’m currently working on addressing all the feedback as fast as I can.
> >>I honestly think this extension is great especially for new users, who
> >>do not know they need reviewers or who would review there change.
> >>Granted this extension has some problems hence why feature requests
> >>were filed against the extension.
>
> +1 to what Niharika and other have said: thank you for all your work on
> Gerrit, Paladox!
>
> You have made maintaining and keeping Gerrit secure easier for me
> personally.
>
> Thanks all for your thoughts on this thread, and thank you in advance for
> ensuring the task for suggestions for improvement is accurate.
>
> -- Tyler
>
> [0]. <https://tools.wmflabs.org/sal/log/AWh2D-odA1BDhGjCUFA8>
> [1]. <https://phabricator.wikimedia.org/T214397>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
Amir
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
123