Hi, sorry everyone. I was busy organizing hackathon and also preparing for a MediaWiki workshop. @Charlie_WMDE thanks a lot for sharing the mockup. I will work on it and change the UI accordingly.

Hi, did anyone test the latest patch? :)

HacktoberFest is arriving. Potential opportunity to bring newcomers to Wikimedia Tech. :)

Hi @Lea_WMDE. Thank you for your feedback. Based on your suggestions, I have amended my current patch and updated it taking into account different parameters (days, months etc). You can check the patch 2 here: Patch 2.

So, I thought of a different approach for this task which creates a better UI

Sure! @Charlie_WMDE. However, you can download the patch and test it locally and let me know how can we make it better.

Hi @Charlie_WMDE, I tried but the tooltip doesn't automatically show on render. I will upload a [WIP] patch to show a basic structure.

This tooltip will not be triggered on hover. It will be shown as a "tooltip" permanently. It will not be triggered on an event such as hover etc.

In T136104#4509222, @IKhitron wrote:

It will not work on desktop version of mobiles

Instead of showing the text above the marker, what if we show it as a tooltip?

In T136104#4498127, @WMDE-Fisch wrote:

In T136104#4492148, @wassan.anmol117 wrote:

Are we showing the labels on the basis of a pre-defined time frame (say, a month) or is it based on the number of contributions? From what I understand, it is based on the number of contributions within a particular time frame. Well, this will make it a much wider problem because there are articles that have more than 30 changes in a particular day. Check this for example: Revision History of Helicopter 66
So, we need to take into account the number of contributions within a time frame and that time frame can be anything. It can be a day, a couple of days, a week, a month, few months, an year.

Yeah, the idea would be not to have a fixed timeframe. As you said, the revisions per time unit can vary a lot depending on the article. My rough idea here would be:

• look at a certain set of revisions ( eg. the number of revisions that is currently visible )
• get the delta what time has passed from the first revision to the last revision in your set
• depending on that delta have a fixed set of applicable scales e.g.:
  • if the time between rev first and rev last is a year have a scale with maybe months
  • if the time between rev first and rev last is a day have a scale with hours
  • etc...
• then iterate over the revisions and apply markers where the selected scale units are hit

:-)

Proposed solution that I have think of: Keep the height intact (same) for all changes having < 100 bytes (both positive and negative). Let the logarithmic algorithm calculate the height if it's equal or greater than 100 bytes.

I am interested in working on this task.

I was reading and understanding the problem statement. I have a question. Are we showing the labels on the basis of a pre-defined time frame (say, a month) or is it based on the number of contributions? From what I understand, it is based on the number of contributions within a particular time frame. Well, this will make it a much wider problem because there are articles that have more than 30 changes in a particular day. Check this for example: Revision History of Helicopter 66
So, we need to take into account the number of contributions within a time frame and that time frame can be anything. It can be a day, a couple of days, a week, a month, few months, an year.
Is there something that I am missing?
Please correct me if I am wrong somewhere.

I realize where I was wrong. Thank you! I think this ticket can be closed.

Okay, so now a simple query like this:

Hi! I am interested and also at the Wikimania. I was there at the hackathon yesterday working on the broken BUB tool. Would love to meet @Lea_WMDE and @Bmueller. Thanks!

Can't reproduce it on Firefox 60 and Chrome 67.

Interesting thought! I have seen many newcomers coming from platforms like you mentioned above and stay and contribute for a long time. Many newcomers visit these sites in order to kickstart their open-source development. If few of the beginner bugs get posted on these websites, we can get a lot of new contributors. The bugs that we usually provide to Google Code-In students, would be a decent way to start, in my opinion. :)

Sorry for the delay. But here is the link to my blog post: https://mywikieducation.blogspot.in/2017/09/wikimania-hackathon-2017.html

Alright, you were correct. It was my bad. I just opened the same link twice. Apologies for the same.
Well, this ::after pseudo-element is causing the trouble. The ::after pseudo-element is not used here.

I will take care of it in future. Thank you, @Aklapper :)

Alright, @D3r1ck01 I need to dig too for the information. :)
I think this has to do something with https://gerrit.wikimedia.org/r/#/c/363264/ if it has happened all of a sudden. Can you please tell me your ISP and country from where you tried to access the image?

Can't reproduce it on Firefox 54 and Chrome 59.

@Volker_E Yes, I mean vertically. Here is the screenshot:

I get the 200 status on Chrome and Firefox. Can you provide some more information?

Issue reproduced on Opera 46.

It is specifically mentioned here (https://github.com/wikimedia/mediawiki-extensions-PageAssessments/blob/68c5a3f7921abe9f923b85d8129bd3709dbd76ac/api/ApiQueryPageAssessments.php#L29) that projects will be displayed always one more than the limit. Should we change it?

I found the deprecated MySQL extension functions here as well: GitHub

I tried on my Android version 6.0 running Amigo OS 3.2.0 using Google Chrome 58.0.3029.83 and wasn't able to reproduce either. Please mention the version of Android and browser.

I'd like to volunteer.

Patch set 3 uploaded. Link: https://gerrit.wikimedia.org/r/#/c/343024

Patch set 2 uploaded. Link: https://gerrit.wikimedia.org/r/#/c/343024

I have been noticing it from my last two tasks. I have to explicitly mention the gerrit link here even after tagging the correct Phab ticket in the commit message.

@phuedx: I am is to blame. I wrote the comment mentioning the gerrit link and forgot to submit it. I just checked it now. I apologize for it.

@Aklapper: I uploaded a patchset. Here is the link: https://gerrit.wikimedia.org/r/#/c/342901/

I would like to do the task. :)

So, if we add a code that handles this exception, would it solve the problem? Or is there any other way to do it?

Adding a

session_start();

at the top and setting the $_SESSION variable should solve this problem.

POSSIBLE CHANGES IN "BetaFeatures" EXTENSION
• Probably, we will have to make a new module or modify an existing module for enabling the features in mobile and have to define the 'targets'.
• 'targets' must be set to mobile.
• MobileFrontend's "Minerva" skin might prove handy.