I think this pull request would help with at least the second search link.

Sounds good, thank you!

Oh nice, thanks for the quick and helpful response! This pretty much solves my problem.

Hi, those indexes are autogenerated so I guess they don't need to be migrated and we can just let the cronjob rebuild them as needed, if that's easier.

Hi, thank you all again for your submissions! We chose @AikoChou for this project couple of weeks ago. Sorry we never wrote back here -- I actually thought applicants would get some communication through the Outreachy platform.

Thank you all for your submissions! I'm looking through them and they will very much be considered along with the final submission (deadline November 5th, as @Samwalton9 mentioned), even if I don't make further comments on GitHub :)

@AikoChou @Kendallcorner Thank you! I hope to have a look in the next few days (weekend is more realistic) and leave some comments as an issue on the repository :)

In T234606#5562504, @Ghassanmas wrote:

@Surlycyborg But the mediawiki API usually returns the disambiguation page or the redirect page not the exact article. which would need to send another request assuming the redirect is correct or the first result of the disambiguation is correct. But if using the search API before then we could get the article by pageid instead.

In T234606#5553671, @Achillesheel02 wrote:

Hi @Miriam @Surlycyborg,
Here's my repo: https://github.com/achillesheel02/wikimedia-citation-classification-task-2.git
Thank you.

In T234519#5550636, @KalindiFonda wrote:

Hello! I found it useful to install the packages in a virtual environment, had some issues probably with packages from before, and having a virtual environment solved the "No module found" errors. Here is some info: https://docs.python-guide.org/dev/virtualenvs/

Those sections typically don't have a lot of usable text that is not links or references, so I think no, we can just ignore those.

That is probably a question for @Miriam - I imagine we want the same level of section title that was used to train the model.

1. Outreachy will ask us to choose an applicant around mid- to end-October according to their timeline, which we'll do based on which tasks they have completed, and how. We have no deadlines other than that - so let's say, any time in the next couple of weeks is perfectly fine.
2. I believe question 2 was answered a couple of comments ago: so, email for this one, please. You can find Miriam's email in this user page, but I'll also edit this and the parent task to make that obvious, sorry for the omission.
3. This and https://phabricator.wikimedia.org/T234606 are the only onboarding tasks we have in mind.

Sorry, that was a bit ambiguous I guess :) I mean to make a comment on this Phabricator entry, like we're doing now, with the URL to your repository.

The only deadline is really the Application period for Outreachy, which goes until mid-October.

This is great, thank you for jumping on this @Magnus !

Hi, if the lower limit is here to stay, would it make sense to make a quick announcement in labs-l, or perhaps even a note to tools that have offended the limit in the past N days? Apologies if this was done and I missed it, but I can't seem to find it. Per-user limits make perfect sense, and I'm adapting my batch jobs to it, but an email would have saved a bit of head-scratching as I saw my jobs failing.

OK, I've just deployed the fixes for the two issues I mentioned above: nicer retries and removing the extra CREATE commands from the serving path.

If there is still impact to Toolforge and reasonable evidence that this tool is responsible, please feel free to disable it. Otherwise, that seems unwarranted. As I mentioned above, it makes a lot of sense to remove the rendundant CREATEs and I hope to do it over the weekend, but it doesn't sound like we should be treating this as an urgent issue at this stage (fwiw the tool has had these extra statements for the past 4 years).

Sorry, I haven't got around to it yet. Hope to get to it in the next few days though, it should be tracked in the GitHub issues I mentioned above.

Thanks! Yes, sql tools does work now. Good luck with the rest of the recovery!

OK, so this morning I'd already disabled the batch jobs that make the heaviest use of the database, and we can definitely survive without them until Toolforge is fully recovered. However, the tool itself is still down (https://tools.wmflabs.org/citationhunt) and I still don't seem to have access to the database:

Hi, thanks for filing this. Here's some background I have:

In T203016#4542459, @jmatazzoni wrote:

. Trust me that there is nothing self-explanatory about this. I don't know what a Petscan ID is. So...I'm stuck, a non-starter.

Link to the tool: https://tools.wmflabs.org/worklist-tool .

@Aklapper, right, I believe @Meghasharma213, the GSoC student I mentored in writing the tool, is interested in staying around as a volunteer to develop and maintain the tool. I think I'll also be able to do some work on it sporadically, but Megha will likely remain the main developer going forward.

We've accepted @Meghasharma213 for this project. Congratulations!

The Phabricator task will be considered the draft and the PDF file uploaded to Google is the final proposal, but they should really just look the same.

My idea was that if the list with same name already exists, then why create a new one? Why can't people add the articles to the existing list only? But still, we can discuss it before implementation. For now, should I let it remain as such in the proposal?

Quick reminder to students applying for this: it seems you're required to submit your proposal both as a Phabricator task and a PDF to Google, as per step 9 in https://www.mediawiki.org/wiki/Google_Summer_of_Code/Participants.

Cool, this looks great and is just about ready for final submission. I've made a few more comments below but none are blocking to the proposal -- I'm convinced you understand the problem and have a plan to solve it :)

Very nice, thank you! I'll make some inline comments below, but generally I like the extra features you've suggested, and I'd like to see a bit more detail on how you'd design and implement some of the things you've mentioned. Do let me know if you have any questions of course.

Hi @Meghasharma213 -- great to hear you're interested! I'm definitely planning on being extra-available for feedback and finishing touches on proposals over the next few days, so it might actually not be a big deal that you're late: we'll just iterate faster :) Just let us know when you have something and we'll take a look!

I think different users can view each other's worklists right? Do we have a purpose to show only the loggedin user's worklists on the home page? If yes, we are already storing 'created_by' in the worklist table. It would be easy to filter the worklists for the current loggedin user.

Hey, nice to see this taking shape. Here's a couple more questions / comments based on your proposal and things that came up when I last met with the other mentors.

In T188979#4042570, @BamLifa wrote:

Many thanks for your comments and suggestions that seem very intersting.

I thing that most of info are already on my proposal a part from the front end. When I say

To design the database architecture and refine specs

It is all about db architecture and implementation. Unless you require me to put more detail.

Great, thanks for the answers! By the way, you're probably planning to do this already, but please move the results of these conversations we're having into the proposal itself at some point, just so it's complete and self-contained.

Hey, thank you for this! By the way, I'd left some comments on https://semestriel.framapad.org/p/functional-spec-gsoc18 which you could address here.

Sorry for the delay, I've left some inline comments on your Google doc. Thanks for submitting this!

@BamLifa Awesome, thank you! I've left a few comments in the Framapad. @Sadads you may also want to have a look at that if you get a chance, please.

Nice, thank you! I can take a closer look in the morning :)

Hey, sure, thanks for asking. I'm in UTC.

I've left a couple of questions and ideas in an issue in @AdityaJ 's repository to help prepare for the proposal.

@BamLifa Very cool, that was fast! I've filed an issue in your repository with a suggestion that I think we'll need (and also updated the original project description to make it more explicit). Let me know if you have questions or problems :)

I've added some more information to the initial post, including the mentors and points of contact and some suggestions for small tasks that applicants can start on before writing their proposal.

I believe the idea would be to have this as a separate tool, not an on-wiki gadget. I'm not too familiar with gadgets, so please correct me if I'm wrong, but my understanding is that they'd typically be used to augment existing wiki pages, right? The idea here would be to have a tool that, given as input a selection of articles, facilitates collaboration for multiple users editing those articles, so it doesn't seem like a great use case for a gadget.

I'm most likely going to throw away this prototype, so there's no point pursuing this. Thank you all for your input!

The code is here: https://github.com/eggpi/similarity/blob/master/app.py . Basically I'm trying to load a ~400MiB pickled file in the tool's home directory at start-up. That file contains a sparse matrix that gets traversed on each request.

Hmm, I did try a couple more low-hanging fruits to reduce the size of the data, which does make a difference locally. Still no luck launching the tool on the grid though.

Thanks for reporting!

It's working again. Thank you very much!