Hi Roy,

Thank you for your interest! Your background sounds great. I like Django too, but think it may be overkill for this particular project. Nothing is set in stone, though, and I appreciate suggestions on the tech stack we end up going with. A few other people have expressed interest too, so I will give it a few days and get back to everybody early next week. If you have any questions in the meantime, please let me know.

-- Slavina Stefanova (she/her) Software Engineer - Technical Engagement

Wikimedia Foundation

On Tue, Sep 6, 2022 at 3:53 PM Roy Smith roy@panix.com wrote:

Hi. I might be interested. I'm expert in Python, and have some experience with Flask. I'm the author of spi-tools https://github.com/roysmith/spi-tools, which was done in Django, but I've come around to thinking that Flask probably would have been a better choice.

I have minimal front-end / javascript skills, but wouldn't mind getting some exposure to Vue.js.

On Sep 6, 2022, at 5:24 AM, Slavina Stefanova sstefanova@wikimedia.org wrote:

Hello all,

I am looking for someone to join me as a co-mentor for the Outreachy 2022 December cohort. I’m a former Outreachy intern and currently working as a software engineer with the Technical Engagement team at WMF.

The project is detailed in this Phabricator task[0]. It will be a web app similar to the tool Citation Hunt[1]. If you have some experience developing web applications, this could be a good opportunity to get involved on the mentoring side. You don’t have to know everything, as long as you have sufficient skills in either frontend, backend, or design. New mentors are welcome!

The time commitment is around 5h/week from December to March, and during the contribution and applicant selection phase in October.

You are welcome to email me with any questions, or ask them directly in this thread.

Also, if you aren’t interested yourself but know someone who might be, please spread the word <3

Thanks, Slavina

[0] https://phabricator.wikimedia.org/T317083 [1] https://citationhunt.toolforge.org/

-- Slavina Stefanova (she/her) Software Engineer - Technical Engagement

Wikimedia Foundation

On Wed, Aug 17, 2022 at 2:46 PM Srishti Sethi ssethi@wikimedia.org wrote:

...

Hello everyone,

Wikimedia is participating in the winter edition of this year's Outreachy https://www.outreachy.org/ [1] (December 2022–March 2023)! The deadline to submit projects on the Outreachy website is September 30th, 2022. We are currently working on a list of interesting project ideas. If you have some ideas for coding or non-coding (design, documentation, translation, outreach, research) projects, share them here: < https://phabricator.wikimedia.org/T313361%3E [2].

*About the Outreachy program* Outreachy offers three-month internships to work remotely in Free and Open Source Software (FOSS), coding, and non-coding projects with experienced mentors. These internships run twice a year–from May to August and December to March. Interns are paid a stipend of USD 7000 for the three months of work. Interns often find employment after their internship with Outreachy sponsors or jobs that use the skills they learned during their internship. This program is open to both students and non-students. Outreachy expressly invites the following people to apply:

• Women (both cis and trans), trans men, and genderqueer people.
• Anyone who faces under-representation, systematic bias, or

discrimination in the technology industry in their country of residence.

• Residents and nationals of the United States of any gender who are

Black/African American, Hispanic/Latinx, Native American/American Indian, Alaska Native, Native Hawaiian, or Pacific Islander.

See a blog post highlighting the experiences and outcomes of interns who participated in a previous round of Outreachy with Wikimedia < https://techblog.wikimedia.org/2021/06/02/outreachy-round-21-experiences-and... [3]

*Tips for mentors for proposing projects*

• Follow this task description template when you propose a project in

Phabricator: < https://phabricator.wikimedia.org/tag/outreach-programs-projects%3E [4]. Add #Outreachy-Round-25 tag.

• Project should require an experienced developer ~15 days and a newcomer

~3 months to complete.

• Each project should have at least two mentors, with one of them holding

a technical background.

• Ideally, the project has no tight deadlines, a moderate learning curve,

and fewer dependencies on Wikimedia's core infrastructure. Projects addressing the needs of a language community are most welcome.

• If you don't have an idea in mind and would like to pick one from an

existing list, check out these projects: < https://phabricator.wikimedia.org/tag/outreach-programs-projects/%3E [4]

• To learn more about the roles and responsibilities of mentors, visit

our resources on MediaWiki.org: < https://www.mediawiki.org/wiki/Outreachy/Mentors%3E [5].

We look forward to your participation!

Cheers, Srishti

[1] https://www.outreachy.org/

[2] https://phabricator.wikimedia.org/T313361

[3] https://techblog.wikimedia.org/2021/06/02/outreachy-round-21-experiences-and...

[4] https://phabricator.wikimedia.org/tag/outreach-programs-projects/

[5] https://www.mediawiki.org/wiki/Outreachy/Mentors

*Srishti Sethi* Senior Developer Advocate Wikimedia Foundation https://wikimediafoundation.org/

---

Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org

https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

---

Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

---

Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

I assume the plan is to do this in Toolforge? There's a few things about Toolforge that I bristle at, but it does give a lot of value in the stuff you get for free. I don't see any viable alternative for a small project like this.

Toolforge is an option; Cloud VPS is also possible if we need something more flexible.

On a side note, I'd be interested in hearing what you dislike about Toolforge, if you'd like to share. We (the cloud services team) are working on improving Toolforge and don't always get as much feedback, good or bad, as we'd want.

-- Slavina Stefanova (she/her) Software Engineer - Technical Engagement

Wikimedia Foundation

On Wed, Sep 7, 2022 at 3:08 PM Roy Smith roy@panix.com wrote:

Just from my personal experience, I see django as a good "batteries included" solution that lets you get something up and running quickly because it gives you all the pieces in one package. But I've found that I tend to actually use very little of it.

I tend not to use the django database/model stuff. On my one large-scale django project, we used mongodb with mongoengine for the ORM layer. On spi-tools, I'm using redis.

I've totally sworn off django templates in favor of Jinja, even at the cost of breaking some of the neat test client tools django supplies.

I kind of like django's middleware system, but in practice I find it a little too complicated, mostly because django doesn't provide a good way to pass around per-request context. So you end up shoving your own data into django's HttpRequest, which is kind of evil. Or you use thread local storage, which always seems a little sketchy. Flask at least attacks the problem head-on by providing you with an explicit global object to use. It may be thread locals under the covers, but at least it's officially supported.

I like Flask's decorator-based routing better than Django's url.py system.

But, with all that, I've got a few production Django systems under my belt and have only just toyed with Flask enough to get a feel for how it works.

I assume the plan is to do this in Toolforge? There's a few things about Toolforge that I bristle at, but it does give a lot of value in the stuff you get for free. I don't see any viable alternative for a small project like this.

On Sep 7, 2022, at 4:23 AM, Slavina Stefanova sstefanova@wikimedia.org wrote:

I appreciate suggestions on the tech stack we end up going with.

---

Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

Hi Slavina,

I hope you don't mind me jumping in, but here are a couple things I did not find intuitive when I started using Toolforge. I've been using PHP/cPanel style web hosts since around year 2000 so I was expecting an experience similar to that, but I encountered a couple of "gotchyas" that surprised me and slowed down my onboarding. Windows 10 user here.

- FTP programs that aren't WinSCP with "environment -> SFTP -> server -> sudo -u tools.novem-bot /usr/lib/sftp-server" configured appear to the user to work, but create some hard-to-track-down bugs because files have the wrong owner. For example I tried using FileZilla Client before I found the tutorial. Suggested fix: give a separate login for each tool folder, so that you don't have to sudo.

- Other Toolforge users can view all my files by default, including my password files, unless I manually set them to 0600. Security issue, imo. Suggested fix: Perhaps only admins should be able to view other people's files, and perhaps create a page that is watchlisted by Toolforge admins to request copies of other people's files minus their password files.

- Kubernetes is not intuitive and has a learning curve. Suggested fix: Perhaps a GUI control panel should be created that auto-creates cronjobs.yaml files, generates the interval for you (e.g. 01 13 * * *), lets you pick the image from a dropdown box, and executes kubernetes commands such as kubectl apply --validate=true -f $HOME/cronjobs.yaml, kubectl delete cronjob task-a, kubectl get pods, kubectl logs [pod name], etc. with the push of the appropriate button.

Hope that helps. Thanks and have a great day.

Novem Linguae

On 9/7/2022 7:30 AM, Roy Smith wrote:

The biggest issues I see are the lack of any good logging, monitoring and alerting tools.  Things like icinga, logstash, grafina.  The kind of things that are standard for supporting any production system.  I've raised this before, so I won't belabor the point here.

And https://phabricator.wikimedia.org/T256426%C2%A0continues to be an every-day pain in my side.  The related https://phabricator.wikimedia.org/T127367%C2%A0is triaged as high priority.  It's been open for 6-1/2 years.

...

On Sep 7, 2022, at 10:17 AM, Slavina Stefanova sstefanova@wikimedia.org wrote:

On a side note, I'd be interested in hearing what you dislike about Toolforge, if you'd like to share. We (the cloud services team) are working on improving Toolforge and don't always get as much feedback, good or bad, as we'd want.

---

Wikitech-l mailing list --wikitech-l@lists.wikimedia.org To unsubscribe send an email towikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

Novem Linguae and Roy – thank you both for your insights.

Yes, app-level logging/monitoring could be much better, for sure. And Toolforge is far from intuitive for the average user. We are currently working on new features that will ultimately make Toolforge easier to use, similar to other PaaS offerings out there like Heroku, where users basically just have to point to a repo hosted on GitHub or other VCS, maybe add some config. Hearing which specific things irk people is useful.

-- Slavina Stefanova (she/her) Software Engineer - Technical Engagement

Wikimedia Foundation

On Wed, Sep 7, 2022 at 11:16 PM Roy Smith roy@panix.com wrote:

On Sep 7, 2022, at 4:50 PM, novemlinguae@gmail.com wrote:

• FTP programs that aren't WinSCP with "environment -> SFTP -> server ->

sudo -u tools.novem-bot /usr/lib/sftp-server" configured appear to the user to work, but create some hard-to-track-down bugs because files have the wrong owner. For example I tried using FileZilla Client before I found the tutorial.

My take on this is that Toolforge is unabashedly a linux environment. If there's some incompatibility with a Windows app, that's not toolforge's problem. I log into toolforge with this alias:

alias spi-tools-dev='ssh -t dev.toolforge.org tmux new -A -s spi-tools-dev become spi-tools-dev'

As needed, I set up port tunnels with things like:

alias tunnel='ssh -t dev.toolforge.org -L 23002:localhost:23002 become spi-experiments'

And likewise I can move files in and out with scp. I agree that there's a learning curve to all this ssh stuff (including the associated key management), but hiding that beneath a cPanel veneer just makes it all the more mysterious because you're never really sure what's going on. If you're going to develop in a linux environment, invest the time to learn the linux tools.

Suggested fix: give a separate login for each tool folder, so that you don't have to sudo

Logging in as a person. then gaining some specific additional set of rights with sudo (the "become" utility is really just a thin wrapper around sudo) maintains the appropriate distinction between authentication (who you are) and authorization (what you're allowed to do). If each tool had its own login, then how would multiple people maintain the tool? They'd have to share the password to the account. That's not a good plan.

---

Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/