Wikimedia Technical Conference/2019/Participants
All responses on this page were submitted by participants in their registration form as answers to questions that clearly stated "This will be added to the participants list page on Mediawiki"
Please edit your information as you like!
| What name should appear on your name-tag and on our Mediawiki event page participants list. | What does developer productivity mean to you? | How can participants in the Technical Conference contact you on and off-Wiki? |
|---|---|---|
| Addshore | Being able to look at any part of our platform or product, and effectively work on it with little on boarding, across platforms with little effort. | IRC: Addshore
On wiki: Addshore |
| akosiaris | * Being able to iterately and quickly develop software and deploy new versions in production with a high degree of confidence.
* Being able to rollback quickly and with minimal fuss a problematic deployment * Being able to identify quickly and with minimal effort and guessing the root cause of an incident * Being able to communicate to other developers through a standardized "contract" what a service/software is able to do and the advertised Service Levels Objectives (SLOs) that it can be held accountable for * Having a consensus on what needs to be done when a service/piece of software is not upholding abovesaid Service Level Objectives (SLOs) |
https://meta.wikimedia.org/wiki/User:AKosiaris_(WMF) |
| Amir E. Aharoni | 1. Being able to start implementing your brilliant idea as quickly as possible without having to set up a working environment for several days.
2. Having it usable by as many people as possible, in any project, and in any language without any special effort. 3. Not doing things manually when they can reliably be done automatically. |
Wikipedia: User:Amire80
Twitter: @aharoni Telegram: @amire80 |
| Andre Klapper | Making technical progress, effective and efficient, in meaningful collaboration. | See https://meta.wikimedia.org/wiki/User:AKlapper_(WMF)r |
| Aubrey Williams | The first thing that comes to mind when thinking of developer productivity is collaboration. The feedback you receive from peers or users of the product are invaluable and without these insights, one will not be as productive. | They can add me on Linkedin. The URL is: www.linkedin.com/in/aubrey-williams-6a888896 |
| Birgit Müller | Developer productivity means that technology, processes & culture don’t hinder but enable staff & volunteers alike to onboard fast & to be efficient & creative in their work. For example by using standard solutions so that people don’t have to learn how to work with re_invented wheels, or by designing accessible & equitable processes volunteers, staff & projects will benefit from. | |
| Brennen Bearnes | Devs should be able to reason about and make desirable changes to software with a minimum of unnecessary pain from their tooling, environments, and social context. | BBearnes_(WMF) on wiki, brennen on freenode |
| Brooke Storm (bstorm_) | To me developer productivity is whatever helps the creative work with technology get done. | IRC: bstorm_ and wiki: BStorm (WMF) |
| Bryan Davis | Removing accidental complexity in our FOSS contribution pipeline (for example the need to learn Gerrit workflows), reducing toil by technical contributors (for example providing automatic code formatting via editor integrations and/or external tools), finding better ways to get folks who are comfortable reviewing code in a given area/language to see the patches that need reviewing | bd808@wikimedia.org, bd808 on Freenode, [[mw:User talk:BDavis (WMF)]] |
| Chris Koerner | Being productive means working well together. This involves communication, vulnerability, and camaraderie. | Ping me on Wikimedia Space in a public thread, my User: talk page, or email. |
| Cindy Cicalese | Making sure that developers have adequate tools and support for software development and testing, from local development and testing, to collaborative development and review, to continuous integration and deployment. | ccicalese@wikimedia.org |
| Cormac Parle | I want myself and others to be able to write useful code with a minimum of fuss. I don't want to have to struggle with my dev environment. I want to be able to get help/advice/tips quickly when I need to. I want to be able to understand the intent and the implementation of code I need to read/modify relatively quickly/easily. | email or cormacparle on irc |
| Dan Andreescu | In my opinion, productivity is correlated to ego-less programming and diversity.
The less complicated our architecture is, the more productive we become. And the more newcomers we can welcome to contribute features and fixes, increasing diversity of opinion. |
Username: Milimetric / Milimetric (WMF) |
| Daniel Kinzler | Being able to modify code with confidence. This is helped by simplicity of the existing code, test coverage, documentation, and efficient communication channels. | dkinzler@wikimedia.org |
| Daniel Zahn | Using tools, task manager and code review, effectively to remove the need for working in the same timezone. I want to be able to get code reviews without the need for real-time pings. | dzahn@wikimedia.org |
| Daren Welsh | Clear, specific, and achievable goals that have been integrated with the entire community's road map (which includes broader goals and infrastructure design), testing through peer review, automated testing, and consumer feedback, comprehensive documentation of new and existing code that empowers new developers to onboard and contribute | User:Darenwelsh, darenwelsh@gmail.com |
| deb tankersley | (@debt) email, irc, telegram, gchat | |
| Derk-Jan Hartman [[User:TheDJ]] | productivity for me mostly means not being blocked in achieving my goals | [[User_talk:TheDJ]], Twitter: @dj_hartman |
| Elena Tonkovidova | From my experience working as a QA engineer on quite few WMF project, I saw that including QA best practices into development life cycle unfailingly deliver better products, better user experience, and overall, make developers and project managers more efficient. | etonkovidova@wikimedia.org |
| Emmanuel Engelhart - Kelson | openZIM/Kiwix | kelson@kiwix.org |
| Erika Bjune | The ability for engineers to easily set up a development environment, code with testing, performance and security in mind, and deploy code into production smoothly, using shared processes that help keep them focused on priorities and make it easy to collaborate and experiment. | Email: ebjune@wikimedia.org |
| Eugene233 | Developer productivity means attaining one's goals and completing task given the material and help made available by other developers whom they rely on for the improvement of their work. | Email, IRC |
| Florian Schmidt | Developer productivity to means, that a developer can quickly start contributing with little knowledge about the existing infrastructure and without needing to read through pages and pages of documentation. It also means, that it's easy to get fast feedback from a development environment whether a change is actually good (locally and in CI) and that it did not break any existing features. Additionally to that, getting new features into production is very easy and done fast, as well as getting rid of deprecated or not widely used features as well. | E-Mail: florian.schmidt.stargatewissen@gmail.com |
| Franziska Heine | ||
| Galder Gonzalez, [[User:Theklan]] | Knowing how to get things done is the most difficult task on every organization. At Wikimedia this is speacially challenging. | User page or Phabricator |
| Gergő Tisza (Tgr) | Not having to wait (on other humans or slow tools), not having to find out everything on your own. | https://www.mediawiki.org/wiki/User:Tgr_(WMF) |
| Giuseppe Lavagetto (_joe_) | GLavagetto (WMF) / _joe_ on IRC | |
| Grant Ingersoll, Chief Technology Officer, Wikimedia Foundation | ||
| Greg Grossmeier | Improving the quality and speed (sometimes both) of development. | wiki: User:Greg (WMF)
email: greg@wikimedia.org irc: greg-g |
| Antoine "hashar" Musso | Offering tool and means for developers to produce good quality software. | email: hashar@free.fr
irc: hashar |
| James Forrester | Improving developer productivity is about making it more obvious when things go wrong. Making it clearer how things should work. Providing the feedback about what has changed and why, in ways that are more coherent, more consistent, and more comprehensive. Reducing the risk of each deployment. Assuring the concerns of the developer so that they focus on the change they want to make. Fundamentally, it is about making better, higher quality changes for users faster and more safely. |
On IRC, on Phabricator, on my MediaWiki.org talk page, and elsewhere. |
| Jeena Huneidi | I aim to help developers be more efficient, reduce bugs, and save time through automation of development and testing ecosystems and striving for continuous integration and deployment. | email: jhuneidi@wikimedia.org irc: longma |
| JHernandez | Tooling that is helpful and doesn't waste developers' time. Code that is easy to understand and change with confidence. APIs that are explorable, type safe, versioned, and easy to consume. Infrastructure that empowers developers to get the job done, develop locally, and understand how their products and services are performing and being used. | mw:User:JHernandez_(WMF) / jhernandez@wikimedia.org |
| Josephine Lim (@misaochan) | User talk page, email | |
| JR Branaa | Developer productivity is less about quantity of output and more about quality of output and the degree of enjoyment related to the daily work of software development. | jbranaa@wikimedia.org, IRC: jrbranaa (#wikimedia-codehealth) |
| Kosta Harlan (@kostajh) | Having tools that support me and accelerate my work as opposed to slowing me down and causing frustration. | KHarlan_(WMF) on wiki, @kostajh on IRC, telegram, phabricator |
| Leszek Manicki (WMDE) | email: first . last @wikimedia.de
WMDE-leszek on gerrit/phabricator User:Leszek Manicki (WMDE) leszek_wmde on freenode | |
| Máté Szabó | I consider the following prerequisites to be necessary in order for a developer to be able to productively work on a project: accessible and up-to-date documentation, lack of individual silos, clearly defined workflows, processes and areas of responsibility and a rapid development feedback loop. | mszabo@wikia-inc.com |
| mobrovac | Getting (good) answers quickly, being able to develop locally in an environment that mirrors production as closely as possible, being able to safely experiment with new features/services in production or in a production-like environment | email, mobrovac (wmf) on wiki, mobrovac on irc |
| Mónica Pinedo (WMDE) | It means there are as few hurdles as possible coming in the way of developers - not only related to the architecture and legacy code but also during the testing and roll out phases.
It means that how the developer teams are organised helps them to focus and deliver happily. It means that product management and UX work closely together and with the developer team to achieve the best product possible. It means that the community also understands all that and support it. |
on the following email - monica.pinedo@wikimedia.de |
| Moriel Schottlender | Developer productivity covers all the tools, norms and standards that allow developers to produce consistent products easily in a manner that adheres to Wikimedia's unique standards of accessibility, language, and community support. | MSchottlender-WMF on wiki; @mooeypoo on Phabricator |
| Moritz Schubotz (physikerwelt) | Minimize the "getting side tracked" potential. | See moritzschubotz.de |
| MusikAnimal / Leon | Spending the bulk of your time coding, not setting up or fixing your environment (either locally or production wiki/Cloud Services). You shouldn't be waiting long for your CI build to run, either, and your build shouldn't fail because of other people's work. You should be able to use the latest and greatest technologies to ensure the longevity of your code, and those technologies should be well-documented to allow for independent developer growth (especially for volunteers who don't have coworkers to poke all day). | Special:EmailUser/MusikAnimal or "musikanimal" on IRC |
| Nes | Happy and motivated developers to be creative | Email, tur.neslihan@gmail.com |
| Niharika (User:NKohli (WMF)) | Quick and easy software installation. Seamless code review process. Easy to view test software changes. Easy to deploy new code quickly and reliably. | Niharika on IRC. User:NKohli (WMF) on the wikis. |
| Nikerabbit | Short iteration times, reliable CI, easy setup of development environment, improved code review | Nikerabbit on wikis and IRC |
| Pablo WMDE | Well-maintained go-to solutions for newcomers, freedom to adapt by personal preference, ability to influence the entirety of the stack, experts encouraging the upstreaming of innovation, and a culture to promote the aforementioned. | User:Pablo_Grass_(WMDE) |
| Petr Pchelko | Ability to deliver product without interruptions both technical and social | IRC:Pchelolo or ppchelko@gmail.com |
| Piotr Miazga | Developer productivity is mostly about how easy is to do a single job. Are there any tools that can help developers solve problems? Is there any architectural framework that guides developers on how to implement new features. | pmiazga@wikimedia.org |
| Quiddity / Nick | Removing obstacles and unnecessary complexities from the standard dev workflows | |
| Rachel Farrand | Process improvments and removing blocks for volunteers | rfarrand@wikimedia.org |
| Riccardo Coccioli (volans) | There are so many aspects related to developer productivity. One important aspect to focus on is to increase the confidence of developers and deployers that a change will not be destructive when deployed into production. In order to do that a developer must be able to easily test their changes, both manually and automatically, in an environment as much as possible similar to production. This will also allow to reduce the time to get a patch deployed into production. | https://meta.wikimedia.org/wiki/User:RCoccioli_(WMF) |
| Sam Reed (reedy) | Automation (if it can be done by software, developers shouldn't have to do it be manually). Low barriers to entry (easy to setup). Fast tests | reedy@wikimedia.org |
| Sam Wilson | I'm interested in the developer experience around MediaWiki extensions: writing new ones, contributing to existing ones, advertising them, and working with users to improve them. I think there are lots of things that we could be doing better, and we could learn from projects such as WordPress and Drupal (while avoiding some of the wrong directions they've taken). | User:Samwilson @samwilson https://t.me/freosam |
| Stephen Niedzielski | Changes are as easy as `npm start`, editing the code, and seeing the change. In other words, software is built for change: extremely lightweight and reusable, tools are industry standard and the best available, and the set up is minimal and designed for quick starts and tight development feedback loops. | sniedzielski@wikimedia.org |
| Timo Tijhof \n Krinkle | ||
| Tobi (WMDE) | ||
| Toby Negrin, Chief Product Officer, Wikimedia Foundation | - | |
| Tpt (Thomas) | Developer productivity means helping both volunteer and staff developers to improve the Wikimedia tech platform. It requires good and easy to use tooling and nice and efficient on-boarding experience, especially for volunteers. An other crucial point is to design processes like code review such that everyone could get the same level of support, ranging from the full time staff member working on its team project to the new volunteer dedicating one hour a week to fix bugs in a MediaWiki extension without maintainer. | MediaWiki email system, "Tpt" on IRC/Matrix, Tpt93 on Telegram... |
| Tyler Cipriani (thcipriani) | Developer productivity means that there are tight feedback loops between the developer at each step along the way to production. It also means that Developers have the tools they need to collaborate with one another to take an idea to production as quickly and safely as possible. | IRC - thcipriani; email - tcipriani@wikimedia.org |
| User:X-Savitar (Volunteer Developer) | In my understanding, it's the extend or degree of the ability of developers to build and evolve in software systems, how efficient they can be and how easy the can strive as developers within the software system being developed. | User:X-Savitar (on-wiki), Email: alangiderick@gmail.com (off-wiki) or xSavitar (on IRC Freenode) |
| Vivek Maskara | For me, accountability, ownership, and responsibility are the three most important aspects of ensuring developer productivity. This becomes a lot more important for completely remote teams with people in different timezones. | Email: maskaravivek@gmail.com |
| Volker E. | To be able to focus on the important, more complex tasks and leave the small things aside. | https://www.mediawiki.org/wiki/User:Volker_E._(WMF) |
| Will Doran | It means having greater impact in the work we do, it means being able to build innovative products and tools, and it means creating space for creativity by constructing the best possible environment for engineers | wdoran@wikimedia.org |
| WMDE-Fisch / Christoph Jauera | When I know what I want to achieve, I can easily get input on how to implement that in the best manner. This can be by feedback from experienced developers or/and good written code and documentation. | CFisch_WMDE @ IRC - WMDE-Fisch @ Phab/Gerrit |
| Željko Filipin | Local development environment is easy to set up. Code review is a serious thing. Continuous integration, fast, reliable, easy to set up and update. Deployments are frequent and easy. | User:ZFilipin (WMF), zfilipin@wikimedia.org, Zfilipin at gerrit, zeljkofilipin at phabricator and twitter, zeljkof at freenode and telegram |