Talk:Project management tools/Review

Phabricator

Help

Here's what we'd like to learn from you:

What are the main technical activities you're involved in in the Wikimedia community?
What are your workflows for those activities?
Can you tell us everything you must be able to do?
Similarly, can you tell us everything you would like to be able to do that would make your work easier?

You're more than welcome to share additional information. The more detailed your responses, the more likely it is that your needs will be met by the tool(s) we collectively end up choosing.

Use the button below to create your section, see examples and format your information more easily.

SG (talk)

Technical activities

MediaWiki core development, Flow team.

Workflow

Currently, bugs and features are tracked simultaneously in Mingle (soon to be Trello), Bugzilla, and Gerrit. Discussions happen across all of these platforms, plus via mailing lists, hangouts, Flow pages, and IRC. This has the effect of making our conversations regarding any progress completely disjointed, especially for tasks that take weeks to complete, because the discussion history can be incredibly hard to track.

Must be able to do

Create new feature / refactor tasks, discuss them, and then create subtasks or task dependencies
Review and approve code before merging into master
Restrict user read and/or write access to certain tickets, groups, and repositories
Must be able to query tickets and commits by product, component, status, assignee, and keywords

Would like to be able to do

Be able to control an entire ticket flow from the git command line
Have commit and ticket hooks to report information to IRC

More information

Phabricator does everything we need.

GDubuc (WMF) (talk)

I can't really follow the template because I've just joined and my team (Multimedia)'s workflow is in the middle of a reorganization. We'll probably find a stable way of working in a few weeks, but what we're doing at the moment is a bit irrelevant. However I can comment on Phabricator, having worked with it for a year and a half at deviantART, whose engineering team has a similar size as the WMF.

When I brought up Phrabricator during my interview here I was told that it was initially ruled out because it's incompatible with the WMF workflow/the fact that volunteers submit code. Now that I've had more time to think about it and to see how the work is done here, I don't see why that would be the case.

If anyone has questions about specific things they wonder could/couldn't be done in phabricator, I can probably answer them.

Here's a tentative list of things Phabricator can and can't do that I think are relevant to the WMF:

What it can do

Tasks, not bugs. This is a critical distinction. Bugzilla is too focus on taking care only of bugs. Whereas phabricator can take care of tasks and bugs. In fact, UI teams could use phabricator to handle their task management. Product too. That's a huge difference. For example it was common for me at deviantART to have a general product ticket (assigned to product people) with many smaller dependencies that were actually workable by engineers. Basically it's a lot more freeform and it allows each team to organize their workload with the nature of the tasks being completely different. It also allows engineers to prioritize building tasks and bugs alongside each other.
Rich markup everywhere. Tasks, changesets, commits, etc. can all have rich markup, not just text. This is particularly useful for non-bug tasks.
Code review. The UI for it is just brilliant compared to gerrit. There's just no comparison, phabricator is in another league UI-wise. An example: https://secure.phabricator.com/D7691
Testing integration. Something Phabricator can do is have the local utility used for pushing (arcanist) run the same tests locally, in addition to having the server run automated testing. On this one you can see what it looks like when tests fail: https://secure.phabricator.com/D7691 Unlike jenkins, this is properly built-in and doesn't act as a fake user. It will block merging just the same.
Doesn't require having another remote in git. Changesets are hosted in phabricator itself. This makes a more simplified git experience (basically no need for something like gerrit/master).
Creating automated searches that adds one to reviewers. This is the sort of feature you don't know you needed until you have it. Basically you can track with regexps any changeset or commit. Which means that you can catch people making mistakes as they happen, even if they're being made in a project unrelated to yours. At deviantART this was a brilliant way to make sure that people being onboarded adapted quickly to our best practices.
Search. Uses elastic search, it's pretty good.
Track backlog/performance. The built-in tools are a bit crude but do the job: https://secure.phabricator.com/maniphest/report/burn/?project=PHID-PROJ-69c04afe1fb836349ccc In the case of my project at deviantART, we were one of the few "healthy" ones where the graph of tickets didn't grow permanently (we actually managed to keep it stable). Again, here the integration is really easy and anyone fancying doing more analytics on the raw data could easily do so.
Welcoming 3rd-party contributions. Anyone can push changesets, people with appropriate rights in the project can accept/reject them. Phabricator's own phabricator is a good example of this, many people contribute to it.
Paste. Not need to use pastebin anymore. https://secure.phabricator.com/paste/ And more importantly, pastes can easily be referenced in tasks/commits/diffs, etc.
The phabricator team is very reactive, it's easy to contribute a bugfix and have it merged quickly (in a matter of days).
It has a "serious" mode. By default phabricator has funny wording and encourages the use of macros (usually to include gifs, lolcats and the like), which can put people off. I think that phabricator's phabricator is in that mode. This can be turned off.
Slowvote, documentation, etc. Phabricator has many integration apps that may or may not be useful here. Point is, there is a ton of stuff and a lot of new things coming being actively developed.
It's written in PHP. Which means that pretty much all webdevs at the WMF can hack Phabricator and we could build custom apps to do what we need. For example while at dA, I wrote Skype integration to log our conversations in the "Chatlog" app.
A one-stop-shop overview of one's work. Tasks, code reviews, bugs all seen on an engineer's front page. This is a fantastic way of having visibility over one's own pile of work to do. This is something I really miss here, I find that it requires too much mental gymnastic to have a vision of how many things I have to do, because it's currently split across several tools.

What it can't do

Kanban board. However phabricator is easily extensible/pluggable. At this point, I don't think that Pabricator can replace what people are using Mingle for (organizing cards on a board and moving them). This is probably something we could build as a Phabricator app, though.
Tags. Particularly, sprint tags are missing, afaik. Which means that if you want to tag/search tasks by sprint you need to create virtual projects whose only purpose is to keep track of which sprints a given task has been worked on. Basically you have a year/week number project that all projects use in addition to their own. Eg. a task would be in the "Multimedia", "UploadWizard" and "2014/4", 2014/5" and 2014/6" projects. Meaning that it got worked on during the sprints of weeks 4, 5 and 6 of 2014. This workaround pollutes the "projects" area needlessly, though. That's probably the feature I miss most.
Suggesting tickets when people report an issue. This is actually one of the rare things that WMF's bugzilla instance does better. Phabricator doesn't offer similar tickets when you type a new one, which I guess can result into more dupes. However I've also seen the situation at the WMF where several bugs are being treated in the same long-running ticket, which is detrimental, imho. Coming in late on the bug ticket it's very hard to know what's still current or not. Maybe Phabricator's forced (by the lack of offering similar tickets) approach of having someone manually decide to merge new tasks or not is better than everyone adding comments to a ticket that might not be their exact issue. It does require that someone triages incoming tickets, though.

Khorn (WMF) (talk)

Technical activities

Technically, I'm just fundraising engineering. In practice, I've more or less taken ownership of our Mingle instance, and the working process it describes (we have had zero product people for about a year).

Workflow

Fundraising's Mingle Instance

Description of Mingle Usage

For those of you who don't have collab accounts (for some reason, this is Fundraising's preferred wiki, and we're trying not to fragment), I will attempt to nutshell below.

We currently have six main card types, that relate to eachother in a heirarchy. Briefly, they are:

Triage item: An acknowledgement of the idea that if you make it more difficult (or apparently difficult) to enter a piece of work (bug, feature, whatever) in a system than it is to write the same thing on a post-it note, it will end up on the post-it instead of the system. Triage items are as simple as they get: Just a title and description. It is up to the curator to review triage items and make sure they land in an appropriate place for the tech team (or whomever). Mostly, this item type was created to help bridge the gap between non-tech and tech in fundraising.
Business Goal: Large sweeping overarching goals with large sweeping overarching language. Nothing actually actionable.
Business Capabilities: Incredibly rough descriptions of things the system will have to be capable of, in order to meet our lofty goals. Business goals can contain multiple business capabilities.
Tech Supertask: A vague stab at solving the problem of grouping tasks together in a state of minimum usefulness. Nothing counts as "deployed" until everything in a supertask is deployed. Both business goals and capabilities can contain one or more tech supertasks.
Tech task: Finally, some actual engineering. A description of a defect, coding task, production issue (as in, an issue under the creative team's umbrella), ops action, spike, system upgrade, doc review request, 3rd party issue (tracking), documentation task, or dashboard (visualization) item.
- Tech tasks can belong directly to any card type mentioned above, except for the triage item.
- Tech tasks must belong to a business goal or capability (either directly or through a supertask), to be considered dev ready.
- Tech tasks have priority ( based on our Priority Descriptions, and please disregard every other piece of that page because it's all terrible ), a point-based estimate, and a status that roughly corresponds to standard agile swim lanes.
Sprint: Exists mostly outside of the business value tree. We don't really think of sprints as being uninterruptable blocks of time (can't do it. Too many critical dependencies with third parties that need sudden maintenance with no notice), but rather as a way to filter what we are supposed to care about now, out of the rest of the backlog.

Business value cards are typically assigned to a campaign in the planner view (can't give access to people who aren't project admins) by someone not in tech. Then, sprints are teased out of the chaos based on (for example) the most pressing goals, what the highest priority items directly relate to in the backlog, how much service disruption will be tolerated in the next [time period], etc.

Must be able to do

Alter the workflow in relative significant ways at any time, to accomidate new needs and observations across the whole fundraising team.
See the current sprint's swim lanes, and manpiulate cards on the wall.
Non-tech must be able to enter and track items that only describe business value.
Associate business value items with a campaign / event
Associate technical items with business value items
See all technical items that associate with a specific business item
- ...and generate the aggregate estimate
Track sprint velocity
- Seperate planned velocity from emergency velocity (see priority description).
Generate burnup charts
- ...and work in the emergency work trend
Query for the type of tech work
Query for the relevant codebase
Associate tasks with a larger task, with the implication that the smaller tasks would have no inherent value on their own
Create an ultra-simple (default?) item entry type, which ideally would not even present anything beyond title and description.
Keep track of who created the tech item, and who was working on it last
Mark a task as "blocked" (with comments)
Keep a date for item creation, and a date for every major lane move (particularly "Pending Code Review" and "Deployed")
Keep all our work history together
Create our own custom item views, and save them for future use
Tag items in a freeform way, and query on that tag

Would like to be able to do

Associate tech tasks with more than one business value item. Currently, the business value tree only allows each item to exist up to one time (so it ends up being 1:many on the way down, but only 1:0 or 1:1 for every type on the way up)
Have a tech trend graph that can be manipulated in realtime.
Display an icon next to the card in the swim lane view, if the card is tagged with "Special Deploy Instructions"
Granular security levels for team members - It would be nice if business was somewhat distinct from tech, and everybody could see the planner view without having to be a project admin.
Git commit hooks would be lovely.
Scripts to automatically correct the "Data Problems" that we find sometimes in our backlog.

More information

Maybe later.

Maryana (WMF) (talk)

Technical activities

Product management (previously for Mobile team projects, now for the Core features team/Flow project)

Workflow

Daily

create user stories and design tickets (in Mingle & Trello)
prioritize bugs that have been imported via Bingle from BZ to Mingle
monitor Gerrit patches via IRC bot to see what things people are working on, where things are blocked, etc.

Weekly

file and respond to bugs in Bugzilla and attach relevant bug #s to user story cards in Mingle
test stories/bugs, close bugs that have been resolved in both Mingle & Bugzilla (sometimes bothering to hunt down the Gerrit patch # if it wasn't added to the bug, but mostly not)
link end-users to issues being worked on in Mingle/BZ and update them when they've been resolved
look at files in Dropbox/Commons and attach assets to user stories

A few times a month

respond on Gerrit patches (when they pertain to user-facing copy or behavior)
respond to i18n feedback on translatewiki

Must be able to do

I must be able to:

assign tasks to users
define a task type (bug, feature, enhancement, etc.)
see & search code review, bugs, user stories, translation discussions
find all the above via product / component / status / assignee / sprint / keywords
edit priority, status, and assignees of items
create & save custom views of stories/bugs (e.g., "All reopened Flow bugs")
mark tasks as not actionable/invalid
mark task as "needs more input from person X" & CC those people (sending them notifications)
incorporate design assets into task tracking (add external links or attach files)

Would like to be able to do

I would like to:

get notifications when new tasks appear or task status changes
attach deadlines to tasks
attach checklists to tasks
have anyone – technical or non-technical, part of my project/team or not – file a new bug
have anyone – technical or non-technical, part of my project/team or not – generate an idea for a new user story
hunt down the actual human behind IRC/Gerrit/BZ/Mingle/Translatewiki username and be able to talk to him/her
do all the things I need to do in one place, not 6 (Mingle, Bugzilla, Gerrit, IRC, Translatewiki, Mediawiki.org) or more

I would like to not:

have long product/design/ideology arguments that belong on wiki/mailing list in any task tracking tool
have task type, status and/or priority changed by people who are not assigned to the task and/or working on the product in question
have to change the status/priority of items twice in two separate places
miss things because I forgot to log in to task tracking tool X and/or didn't notice new comment/notification Y
use a crappy, non-intuitive UI for simple everyday project management when there are so many nicer, more user-friendly alternatives out there :)
mistakenly think User:Foo is 2 people because her username onwiki and her username on Bugzilla are different
deal with rudeness or harassment or see it happen to others in any task tracking tool

More information

Just listing out all the tools I use daily/weekly/monthly made my brain hurt.

Tfinc (talk)

Technical activities

What are the main technical activities you're involved in in the Wikimedia community?

Wikimedia Mobile App Team. The team uses trello for all of our activities and we *love* it. Its simple, quick, and *never* gets in our way. Our bugs are fed in through bugello and we prioritize them during each standup.

Any new tool would have to work faster, have built in estimation, and be simpler for us to be motivated to switch. Simply put trello is great for us and we think other teams would benefit from using it.

Workflow

For each of those activities, can you describe the workflow you're using?

Stories are drafted and placed onto the backlog board
Stories are prioritized and flushed out by product ownder
Stories are moved to a sprint board
Acceptance criteria is defined
Stories are estimated
Stories are accepted by developers and move through dev stages
After two weeks the sprint board is closed and a new one is opened fed by the backlog board

Must be able to do

I must be able to add stories through desktop, mobile, tablet
I must be able to see real time changes without reloading the web page for a sprint
I must be able to set story points and see velocity
I must be able to set custom swim lanes
I must be able to see everything that is happening within a sprint without scrolling the screen
I must have one area for the backlog, one area for the current sprint, and one area for the upcoming sprint

Would like to be able to do

I'd like to automatically see sprint velocity graphs without having to make a spreadsheet

More information

Mobile App Team page

Jdforrester (WMF) (talk)

Technical activities

Primarily, feature product management, some project management, and occasional coding for:

VisualEditor core
VisualEditor MediaWiki
OOjs
OOjs UI
UnicodeJS
Beta Features
… others

Workflow

For the product and project management sides:

Raising tickets: bugs, new features, enhancements, technical debt, and tasks [in Bugzilla]
Triaging incoming tickets: evaluating, confirming, prioritising, re-wording, adding detail, splitting/specifying, allocating to component/product, setting as blocking/depending on other ticket, accepting/rejecting, … [in Bugzilla]
Prioritising work for the team: assigning tickets to a developer's (prioritised) stack [mostly in stand-ups and in a tracking Google Doc]
Reviewing changes: consider and test changes made by developers for having met requirements [in Gerrit/Bugzilla]
Marking completed tickets: marking tickets that have been completed as done, assigning to the relevant (weekly) release milestone [in Bugzilla]
Writing release notes: collate all changes made in a given period, write and release [on-wiki, based on Gerrit and Bugzilla data]
Responding to queries: from end users, third party developers, third party sysadmins, etc. [mostly on IRC, by e-mail or on-wiki]

Must be able to do

I MUST be able to:

alter a task ticket to:
- open or close it;
- convert it to a different type;
- change its title, product/component, priority, confirmation, wording;
- be composed of "checklists" of blocking sub-tasks
- add detail/comments to it;
- merge, split, broaden or narrow it;
- assign it to a person and so send them a notification;
- assign it to a (dated) milestone ("sprint"?); and
- accept/reject it (with justification)

The system MUST:

be able to have private/locked tickets for security-related issues
let anyone file a task ticket with a simple account
let anyone read any (non-private) task ticket and all statuses
- and provide simple, short-as-possible- sharable URLs that uniquely identify tickets without login
be the only system we use for all projects, configurations, discussions, designs and others (no roll-your-own-process with Mingle, or github, or …)
allow cross-project dependencies and cleverness
provide a git instance that …
- only allows team members to merge code
- runs automated checks (linting etc.) and tests (unit, integration, browser, …) when code commits are submitted, amended, and approved (and blocks merge on this basis)
provide a dashboard for the review of incoming streams of, custom saved searches of, and individual …
- task tickets
- code commits
transmit all needed streams of tickets and code commits by e-mail to users that need it
store and display the history of a ticket to any interested users

Would like to be able to do

I SHOULD be able to:

alter a task to:
- attach a file (e.g. a design image) to it; and
- lock it from further discussion once closed
receive by e-mail and be able to review incoming streams of, custom saved searches of, and individual …
- translation discussions
write a narrative of the important changes for a milestone (linking to tasks and commits alike) and series of milestones

The system SHOULD:

let anyone file a task using their SUL login transparently
prevent some fields of tickets be altered by non-team members (e.g. acceptance, type, priority)
lock tickets from further discussion once closed (maybe after some period of time?)
show store and display "in-line" the history of a ticket to all users

More information

I wouldn't want to replace IRC for this, but I'd love to junk Bugzilla and the Google Doc (I actually rather like gerrit, but I'm somewhat alone in this); we've previously used Trello, Mingle; Google Spreadsheet and other things for the task management side, and they all suck – it's just a question of how much less they suck.

Legoktm (talk)

Latest comment: 10 years ago1 comment1 person in discussion

Technical activities

What are the main technical activities you're involved in in the Wikimedia community?

MediaWiki core development, extension developer, tech ambassador, third-party wiki farm sysadmin

Workflow

For each of those activities, can you describe the workflow you're using?

Find a bug/feature I want, either manually or by observing a comment on w:VPT, IRC, or any other page
File the bug in bugzilla, maybe ping a few people in IRC to make sure its feasible (if I don't know that already)
cc the people who are best suited to fixing the bug if necessary
Submit patch in gerrit
Get reviews (usually bug a few people on IRC), patch is merged, yay!

Must be able to do

Using the workflow you've described above, can you tell us everything you must be able to do?

I must be able to view a list of bugs for a given component and filter them based on various fields/keywords
I must be able to set an assignee for a bug
I must be able to provide a stable permanent link for the issue
It must have a decent search engine
I must be able to cross-reference the bug in gerrit (or whatever code review tool) and vice-versa, preferably automatically
Anyone (who isn't a spammer/vandal) must be able to comment on the bug
I must receive email notifications whenever a bug I filed/am assigned to/cc'd on is updated
There must be some kind of real-time notifications feed, preferably IRC
Edit patches/code in my browser (gerrit doesn't support this, and it cripples me)
Any tool used must have an API
Should not be super slow to load and stall your browser when opening large files (like gerrit does)

Would like to be able to do

Similarly, can you tell us everything you would like to be able to do that would make your work easier?

I should be able to "mute" a thread (github has this feature) to stop receiving notifications about it, regardless of anything else
If a bug is linked on wiki, it's nice to be able to see the status/title of the bug (there is currently a gadget for this)

More information

More to come when I think of it. Legoktm (talk) 22:24, 14 January 2014 (UTC)Reply

NEverett (WMF) (talk)

Technical activities

Mostly development on the CirrusSearch extension.
A good deal of monitoring it as it goes into production.
Some work on Mediawiki core and Elasticsearch.

Workflow

I make code changes because (in no particular order):

We notice a bug during the roll out
We notice a performance issue roll out
Community member notices bug during roll out
Community member has great idea
We have great idea

3 & 4 sometimes come from Talk:Search or are filed directly in Bugzilla. Usually I file everything from a community member in Bugzilla for them if they don't file it and sent them a link.

I don't always create Bugzilla bugs for things from 1 & 2 & 5 but I certainly will if they are time consuming, high impact, or I can't solve them right now.

Regardless of whether we have a bug I then make the code change, run some portion of my regression tests, and then submit the change to review in gerrit.

Chad reviews my in changes typically in less than 24 hours and Jenkins merges the code. Normally I use the link in the automatic email to go and mark the bug resolved when the code is merged.

Bugs rarely require multiple change sets but when they do I tend to leave the bug in Assigned state even when one change set is waiting for review.

Sometimes I troll my bug list looking for something to knock out or something that has been merged but not marked as such.

When a bug is nasty I'll verify it in production after it has been deployed then mark it as verified. Sometimes I troll through my resolved unverified bugs and go verify them in production.

Often code changes have corresponding deployment activities and I generally execute those manually.

Must be able to do

File issues and features so other folks can see them or so I'll remember them later or both.
Correlate code changes with issues or features. We do this by adding "Bug: ####" to the commit message.
Mark code as requiring a deployment activity.
Know whenever code that requires a deployment activity goes to production. I deploy much of my code myself but I need to know if other people deploy it as well.
Keep a backlog of deployment activities that have yet to be run in production. Most deployment activities are optional but enable code cleanup or improve some behaviour.
Sweep issues and features from my "backlog" when their code is merged.

Would like to be able to do

Automatically RESOLVE bugs when the code is merged. Maybe I can mark my commit message as "Closes Bug: ####" rather than "Bug: ###". Most commits that reference bugs RESOLVE them when merged.
Automatically mark issues and features as deployed to production when they are deployed. This would really help with manually verifying once it is deployed and notifying the community.

More information

Matthew Flaschen

Latest comment: 10 years ago2 comments1 person in discussion

Technical activities

What are the main technical activities you're involved in in the Wikimedia community?

I'm a software engineer on the Growth team. Primarily, I work on extensions, such as GettingStarted and GuidedTour. I also contribute to other repositories, such as core, in some cases. Last summer, I mentored two students for Google Summer of Code.

Workflow

For each of those activities, can you describe the workflow you're using?

Our team currently uses Trello, a proprietary project management tool, as the primary tool for organizing our sprints. I have been trying to reduce the amount of work I do that is not tracked as part of the sprint. We have a sprint planning session every two weeks. The primary purpose of sprint planning is to move things from the backlog (everything we want to do at some point in the future) to "Current To Do" (what we want to do this sprint). Occasionally, I also do things in Bugzilla, either without it being part of the sprint (as noted above, trying to reduce this), or after importing it into Trello, and it being planned into the sprint.

When I start a task, I move the card from "Current To Do" to "Doing". I then set about doing the task. Usually, this involves a change to an extension git repository, but it could also be a configuration change, planning, improving our own processes and tools (e.g. improving our Wikimedia Labs setup), or running a script.

When a card is done, I move it to Done in Trello. For code, this may also involve marking a bug RESOLVED FIXED. I do not wait until a patch is deployed before marking it FIXED. Usually, the same is true for Trello, unless there are special concerns (e.g. a configuration change, or a required script run for deployment).

Must be able to do

Using the workflow you've described above, can you tell us everything you must be able to do?

I must be able to see items in the current sprint that are not started, where I am assigned.
I must be able to see items in the current sprint that are in progress, where I am assigned.
I must be able to see items in the current sprint that are done, where I am assigned.
I must be able to file a new item and assign it.
I must be able to CC people without them being considered assigned.

If the system replaces Gerrit as well (git management):

Only people with +2 should be able to approve a patch for merge.
Projects should each be able to configure automated testing, which can be required for merge (voting, which is preferred), or not required for merge (non-voting, ideally temporary).
Comment on a change/issue (cover comment) and inline

Would like to be able to do

I would like to view my team's agile velocity
I would like to filter items by primary area (e.g. GettingStarted, GuidedTour, Drafts).
I would like to be able to see helpful graphs and reports.
I would like to mark that one task blocks another task.
I would like an API, for querying (usable from a MW gadget if possible) and possibly writing (to allow integrations like Bingle).
I would like to see history of status and attribute (priority, keywords, etc.) changes to the task
I would like to put Fixes-Bug or similar in my commit message (bugzilla:53387) and have the task be marked fixed/done when the change is merged (this is not the same as Bug: which just means it's related)

More information

I would strongly prefer we use an open source solution. I think they have matured a lot recently, and there are various options, including Phabricator, Redmine, Trac, and Fulcrum. Many of these allow plugins, so we can "plug in" the exact process we want.

Having our own code (MW core, extensions, etc.) FOSS is a critical part of making our work open and allowing the right to fork. However, this is less realistic if the critical infrastructure supporting our work (project and issue trackers, in this case), are not. Using FOSS tools also means we are more likely to contribute back and help build up the FOSS community we live in.

If we are able to adopt a tool that also supports code review (such as Phabricator), that could make the integration between code review and tasks more smooth (e.g. there could be one thread for discussion, rather than both Gerrit cover comments and Bugzilla comments). Superm401 - Talk 02:48, 16 January 2014 (UTC)Reply

Using a FOSS tool means we can adapt it to our needs and enhance it more easily. This is particularly true if the tool is written in a language many MediaWiki engineers are familiar with (e.g. Phabricator is written in PHP). Superm401 - Talk 18:45, 16 January 2014 (UTC)Reply

Arthur Richards (talk)

Technical activities

What are the main technical activities you're involved in in the Wikimedia community?

Team facilitation (mobile web engineering), agile coaching, Mediawiki extension development (MobileFrontend primarily), process tools development (eg Bingle)

Workflow

The workflow depends on specific activities and needs at the moment, but the overall team workflow for new feature development:

New feature ideas get captured as user stories in Mingle, new cards are added by default to our quarterly backlog
Every iteration, the team (engineering, design, product) selects the work to be done for the upcoming iteration by pulling stories out of the quarterly backlog. We have a special view in Mingle to facilitate this, showing our quarterly backlog, the current iteration's backlog, and the upcoming iteration's backlog. If there is work we want to do but no story card defined, we create a new story on the spot and add it to the appropriate backlog.
When stories have been selected, the team works to fully flush out the stories with a clear user narrative, acceptance criteria, and designs - all done in Mingle (design happens externally, but assets are associated with the cards in Mingle).
The engineers on the team estimate the relative effort required to complete each story; the estimate gets recorded on the card. During estimation, lots of conversation happens that usually results in deeper clarification of the work that needs to be done, unknowns and assumptions get surfaced, etc. We use a tool called 'hatjitsu' to facilitate estimation (http://hatjitsu.wmflabs.org/)
Throughout the planning process, the 'product owner' (product manager working with the team) prioritizes the work to be done by rank ordering the stories in Mingle.
When stories are considered good enough to begin work on by the engineers, cards are given a status of 'ready for development'
When the iteration is kicked off, any unfinished stories from the previous iteration gets pulled into the new iteration (pending product owner approval), and reprioritized against new work to be done
Work does not get assigned to the engineers. Rather, when an engineer is ready to begin work on something, they drag a story out of the 'ready for development' column in Mingle into an 'in development' column. Mingle automatically marks story as 'owned' by the person who dragged the card into 'in development'. That engineer is then responsible for the completion of the work in that story. That doesn't mean they necessarily do all the work, but they make sure it gets done.
When work on a story is complete, the story is moved to a column of 'needs code review', and the story's status is updated appropriately. When this happens, Mingle prompts the user for any pertinent links - we use this to add links to specific patchsets in Gerrit that need review
Engineers then work through code review in Gerrit. When all changes associated with that story are merged, the engineer then moves the card into 'Ready for signoff'
The product owner periodically reviews the 'ready for signoff' column on our story wall in Mingle, and does what s/he can to review whether or not the work has been completed. Work is known to be completed when all acceptance criteria in the story are met. If the work is acceptable, the product owner moves the card into the 'accepted' column in Mingle. If it is not acceptable, then the product owner punts it back to 'ready for development' and alerts the engineer(s). If the product owner can't verify the work on his/her own, they reach out to the engineer(s) to demo the code.
While all this is happening, the team meets 3x per week for 15 minute long 'standup' meetings. The group huddles around our story wall (mingle loaded up on a big monitor), and each engineer answers three questions in turn: 'what have you been up to since we last met?', 'what do you commit to do before we meet again?', 'what is blocking you?'. During this time, we also triage any bugs that have been reported since we last met. Bug cards (which automatically get imported from Bugzilla into our Mingle project via Bingle) are either thrown into a generic bug backlog to be dealt with later, put into the current iteration and prioritized against existing work, or put into the next iteration to get resolved then.
Over the course of an iteration, the team's velocity gets automatically recorded by Mingle. That is, the relative estimation points assigned to all stories that get put into the 'accepted' column on our story wall are summed up. This is our team's velocity. We use this number, averaged over time, to determine how much work we can realistically take on during an iteration

This is, in a nutshell, how our team manages our work around new features and bugs. There are of course anomalies and deviations, but this is the overall gist.

Must be able to do

Using the workflow you've described above, can you tell us everything you must be able to do?

I must be able to manage and track new features and bugs from the same tool
I must be able to use the tool to search for existing stories and bugs by status, iteration, backlog, asignee, tags, title
I must be able to track the status of each story/bug
I must be able to quickly visualize the status of all work in a given iteration
Anonymous access to view bugs/features must be supported, ideally without requiring any kind of user account
I must be able to track estimations
I must be able to view our velocity - for a particular sprint as well as over an arbitrary length of time/number of iterations
I must be able to leverage an API for integrations with other tools
I must be able to give users variable levels of access (eg read-only, create/modify stories, administer project settings)
I must be able to rank order the priority of bugs and stories, and do this across types (eg not only prioritize stories and prioritize bugs, but also prioritized bugs/stories relative to eachother)
I must be able to enforce certain actions be taken when a card's status changes (eg ensure ownership changes happen seamlessly when a card's status changes; ensure that comments be added when a particular status gets updated)
I must be able to generate a burnup/burndown chart
I must be able to export all of our data (users, stories, etc) in a generic/commonly used format (eg csv)
I must be able to access this tool at any time, from anywhere (of course so long as I am connected to the internet)

Would like to be able to do

Similarly, can you tell us everything you would like to be able to do that would make your work easier?

I would like to have bugzilla/gerrit integration - that is, with minimal manual intervention, be able to track bugzilla bug status/comments/etc, automatically associate specific patchsets in gerrit with a story/bug, etc
I would like it to be clear when someone else is updating a story or bug (like, updating the text of the description). Even better, it would be awesome if there were real-time updates to story/bug descriptions and status changes (eg I wouldn't have to refresh a story to see new changes or refresh the wall to see an items status update)
I would like to easily flag when a particular story/bug/task is blocked by something
I would like to be able to easily define/show relationships between stories/bugs (eg story a has a dependency on story z; story c is related to bug y)
I would like to be able to track arbitrary aspects of our projects (eg there were x bugs introduced in y time period, or on average over the last 6 iterations we've seen y bugs introduced)
I would like to be able to export arbitrary chunks of data in a generic/commonly used format (eg csv)
I would like a mobile application or mobile-friendly web interface for the tool
I would like notifications based on arbitrary property changes - eg a story has been moved to 'ready for signoff' and I receive an email alerting me to this fact
I would like to be able to define arbitrary properties for card types

More information

Halfak (WMF) (talk)

Technical activities

Research and Analytics. I support product teams with experimental design and analysis to vet new features. I perform independent research to identify trends and opportunities for making the wiki work better. I also interact with the academic community as a representative of the WMF by publishing papers, reviewing for/participating in conferences and forming collaborations with external researchers.

Workflow

I compress a problem/issue/opportunity/feature/theory into a "Research Question".
- e.g., How successful are newcomers in creating pages in Wikipedia?
I come up with some hypotheses that are testable.
- e.g., Newcomers who create drafts (rather than direct to main namespace) are more likely to (1) have their article accepted once moved and (2) more likely to be retained as a long-term editor.
I design metrics and other proxies that allow me to observe human behavior in the data. Usually "the data" is the MySQL database behind a MediaWiki installation.
- e.g., meta:R:Edit session
I write a set of scripts (usually in python) to extract and transform the data in order to build metrics. At this point, my goal is to get an understand for the "space" that these metrics and their corresponding behaviors occupy. This helps me identify mistakes I've made and get a sense for the context.
- e.g., https://bitbucket.org/halfak/wikimedia-metrics
I load these datasets into an R session and produce plots, statistics and models that help me test my hypotheses. These outputs as well as my thoughts get logged on a Meta Wiki talk page.
- e.g., meta:Research_talk:Module_storage_performance
When I think I've "learned something" (i.e., I've effectively tested my hypotheses), I turn my notes into a writeup that summarizes the critical methods, stats, and visualizations into a proper meta wiki page.
- e.g., meta:Research:Module_storage_performance
Finally, I'll present these results to the Wikimedia foundation (e.g. Media:Anonymous_editors_-_WMF_R&D_showcase_(Dec._2013).pdf), the volunteer community (e.g. [1]) and/or the academic community (see [2]).

Must be able to do

Extract the data we keep for analysis (MySQL, Database dumps, Request logs, etc.)
Run processing code on WMF servers with a large amount of ram and # of cores
Bounce ideas off of product managers, other researchers (WMF and external) and devs
Track & prioritize open research questions
Regularly meet with other researchers to discuss new work
Work for 2-5 hours per day without interruption (asynchronous collaboration)

Would like to be able to do

Break complex problems into recognizable units of work so that it doesn't look like I'm sitting on my hands for a week at a time
Document generalizable results in a way that someone else can find them and make use of them after I'm gone.
Get regular feedback from PMs on research that lead to generalizable results.

Christopher Johnson (WMDE)

Technical activities

Software Development and Engineering

Workflow

Development Process

Tools

Tickets: Bugzilla
Distributed Version Control: Gerrit and Github
Code Review: Gerrit
Testing
- Frameworks: Selenium, QUnit, PHPUnit
Continuous Integration: Jenkins and Travis
Dependency Management: Composer
Gating: Zuul
Agile Project Management: Office Whiteboard and Scrumbugz in Evaluation
Analytics: Scrutinizer

Must be able to do

Continuously Develop mw:Wikibase/Components
Coordinate with Foundation Deployment
Respond to Community
Manage Resources for WMDE Internal Software Development Projects

Would like to be able to do

Organize Tickets with Agile Method (e.g. Scrumbugz)
Develop Analytical Methods and Tools for Resource Availability and Visualization with Agile
Monitor and Report Project Results and Objective Criteria Achievement
Consolidate and Manage Documentation for Internal and External Purposes

MZMcBride

Technical activities

I'm here and there.

Workflow

I mostly watch IRC and occasionally check my e-mail inbox. This system works fairly well.

Must be able to do

Code development (file bugs, review code, etc.).

Would like to be able to do

Magic.

MarkTraceur (talk)

Technical activities

MediaWiki core development, MediaWiki extension development, continuous integration setup and configuration, work on various bots, work on other tools, deployments

Workflow

Core/extension development: Usually I'll pick a card off of a Mingle wall, or pick a bug out of a list. Then, I'll analyse the situation, note that I'm claiming the bug or card, create a new branch in my local git repository, and start work. When work is done, I'll run git-review to put the change into Gerrit, ideally with a bug number, else with a link to a card. Then, I'll note in the card or bug report that there's a patch awaiting review, and wait. Finally I'll address any issues and push to get the patch merged.
CI setup and configuration: For the most part this work gets done when we realize we need to do it - there's not really any planning, it's just an immediate feedback situation. A need arises, someone pushes a patch, self-reviews, then deploys.
Bots and other tools: Generally this will happen on a very limited timeframe, and the only organization that will happen is over IRC - no bugs or cards to speak of. If anything, it might happen over GitHub issues.

Must be able to do

THERE CAN BE ONLY ONE.
Query tickets by project, component, team, owner, status, tags, difficulty...
Have custom tags

Would like to be able to do

See items by status in a grid - Mingle has corrupted me (but we could probably hack this together relatively easily)
Have customizable values to set in each ticket
Attach code to tickets
Have new contributors be comfortable with the interface

More information

I really like the idea of using GitLab for most of this. It has a very GitHub-like interface, which contributors will appreciate. There are definitely some evaluations that need to happen before we can switch, but I think the centralization of issue tracking and code review is a good plan in general.

Mutante (talk)

Technical activities

Operations, Puppet (operations/puppet repo on Gerrit), RT (ops requests), Bugzilla setup and some usage, code review, production deployment, Labs support, general requests like mailman, aliases, maintenance, misc.

Workflow

First, I check RT for new activity. I have widgets on my dashboard showing me "newest unowned tickets" (requests from external) and "operations activity" (what my team mates did). We also have separate "queues" in RT so i can just check "ops-requests" or "core-ops" or "domains" depending on the type of ticket.

If i have a comment I reply to that (creates mail to people).

If I think I have a technical solution/patch for an open issue, I

submit a Gerrit patch set with a suggested fix

add the affected people (requestors, other stakeholders, seniors where needed) as Gerrit reviewers (this creates mail to them asking them to please look at it)

make sure the affected people are added on the RT ticket (also so that they get mail about it) and paste the Gerrit URL to the patchset into the ticket

In the case of Bugzilla bugs I don't have to do much else if i didn't forget to mention the bug number in the message. That gets me auto-updated tickets when something is merged.

If there are both, Bugzilla and RT, tickets, i link them both in Gerrit and to each other, or at least I try to when i notice them.

Then this patch hopefully gets some +1's from others in code review and finally gets merged.

In RT I change the workflow step to "resolved" once something is really done. That also means _really_ deployed, not just suggested. In BZ I change the workflow step to "resolved" to _claim_ it should be done, but I appreciate it when others (ideally the requestor) confirm my claim and then switch to the final step "verified".

Besides that i get a lot of requests on IRC and in my personal inbox.

For IRC requests I try to follow basic GTD principles, like "if it takes under 5 minutes do it right away, if it takes longer create a ticket, no exceptions". That means i try to politely ask people to create tickets (mail to ops-requests@RT) which is also listed in the IRC channel topic of operations. Then I try to process them in the order of coming in, I use the RT web ui for that as explained above. Sometimes I think it's unfair when there are tickets that have been sitting there for long but others are processed first because people ping more on IRC about them. Sometimes ops does sprints together with the specific goal of just looking at _old_ tickets to make sure. Sometimes I also change the sort order in RT to show me oldest things first for that. When i get requests in my personal inbox I just forward them to RT because having a single place to have my requests is very important to me. It's also very important that others in my team see what I'm doing and there is no SPOF.

Must be able to do

track requests to my team and me in a web-based UI that is specifically made for tracking requests. (note: software bug reports are just a subset of requests, bugtracker tools are specialized version of request trackers).

link requests or bugs to code changes in an easy way.

add people/reviewers to a specific bug/request/code change and make sure they're notified about it in some way we all agree on.

expect that everybody I work with actually uses and agrees with the tools we have chosen to work with and doesn't boycott them.

link to my own work log in an easy way to answer the question what I've been doing by just providing one or a few URLs.

not duplicate my actions in multiple tools if it can be avoided.

know what exactly the tool does and at least have a possibility of fixing it if necessary, that means: must be free and open source software and _not_ outsourced.

see progress on tickets and what others are doing if I'm the requestor and I request it from another team.

organize requests/bugs in some way by topic (queues, tags or similar).

hide some tickets from the public for special cases.

give access to certain groups of tickets to certain groups of people. (group/role-based permissions)

Would like to be able to do

Handle Operations and OIT tickets in the same system (again).
Have more replies by people on Gerrit itself when i just add them as reviewers. (I think many people filter this out). I think in many cases the whole discussion could just be on a Gerrit change, where the actual code is being changed. Actually it would be even better than having 2 tickets and a change and having either some info here and some there, or duplicating everything all the time
NOT see tickets that are just closed as "fixed" without giving details on what has actually happened
NOT have to additionally spend time on repeating what i did on Etherpads/wiki pages/lists/tech reports or any new kind of project management tool when all the info should already be in the tickets (but for that everybody would actually have to use the same tool, i know)
NOT have to ping people on IRC, mailing lists/wikis to get reviews on Gerrit (or have the choice of just merging without reviews)
NOT be expected to be on IRC and available for real-time requests except in _real_ emergencies
NOT get requests in my personal inbox
NOT have to find information on Google docs,wiki pages, list archives or any other kind of place besides the actual ticket if it belongs there

Steven Walling

Latest comment: 10 years ago1 comment1 person in discussion

Technical activities

I'm a product manager involved with several components in MediaWiki core and extensions for the Growth team or other Wikimedia Foundation work. I also try and help out with testing, design review, and code review for volunteer patches in core or extensions where I have prior knowledge.

Workflow

For new projects, we start by writing specifications on mediawiki.org, uploading design concepts to Dropbox then eventually Commons, and outlining necessary background research on Meta in the Research namespace. This documentation on-wiki gives us something semi-permanent to reference for user stories and other necessary documentation. The work in the Research namespace helps us document things in a way that works for research analysts as well as community members watching on Meta. We also use Meta to create EventLogging schemas which are essential for us to collect data about new products, particularly because most new products start out as a series of A/B tests.

Once we have specifications on mediawiki.org and Meta, we create Trello cards (view our board) to break up our work in to iterations that are two weeks long (i.e. sprints). Trello cards are ideally work items generally small enough to be an aspect of a product contained in a single user story and/or patch, though we may make tracking cards for larger or more nebulous items like a release, configuration change, or bug fix. Trello cards are manually linked to relevant wiki pages and bugs, and sometimes we also attach design assets or bits of interface copy that don't need a permanent home outside the codebase.

We also typically go through a period of design review, which might include qualitative research (like remote usability testing), as well as experimental design from research analysts. This experimental design or early design feedback often reshapes work to be done before it goes in to a Trello card for developers to act on. These items related to design and data are often Trello cards as well, so I need a tool that works for designers and data analysts, not just developers.

Once items are in Trello and prioritized by the team as part of a sprint, they go through the normal cycle of patch submission, code review, testing (automated and manual in a variety of ways). We also go through a fairly set cycle of A/B tests and documentation of those results. Once a product or test is out on the wikis, it generally gets feedback in the form of mailing list commentary, on-wiki messages, and Bugzilla. These things, if actionable, get fed back in to Trello as to-do items for the current or future sprints.

When projects move to maintenance mode, new ideas and to-do items generally come from Bugzilla. These bugs then get prioritized and dealt with accordingly, sometimes getting fed back in to Trello as one-off items (such as to fix a regression) or as part of a sprint.

Must be able to do

I must be able to list open tasks and change their status.
I must be able to move tasks through a system of "to do", "doing", and "done".
I must be able to see an overview of all tasks/bugs, including on a per-project basis.
- I must be able to filter the open tasks based on type and who they are assigned to.
I must be able to see a feed of activity on all tasks/bugs relevant to me.
- I must be able to subscribe to/follow open tasks without being assigned to them.
- I must be able to get email notifications about updates to bugs/tasks.
I must be able to let anyone view our task list, either without registering or through self-registration.
I must be able to restrict who can edit tasks/bugs on our project to team members only, or least Foundation-only.
I must be able to assign an item to a user.
I must be able to make a task that is not necesarily tied to a bug or a piece of code. For example: design tasks or data analysis tasks.

Would like to be able to do

I would like there to be one place to see everything, whether it's a bug, open task item, user story, or patch. Right now it's in at least four different places: Bugzilla, Trello, wiki, Gerrit. I realize this is partially in conflict with giving us full control over what tasks we are assigned and will actually complete, but that's why we invented permissions systems. ;)
I would like to be able to view reporting tools, like a burndown chart or simple statistics on completed work.
I would like a mobile app (iOS is what I use, but basically app means Android and iOS) to be able to get notifications and update tasks etc.
I would like to be able to apply arbitrary and easily changeable tags/labels to tasks/bugs. This allows for both things like "needs QA" as well as priority.

More information

In my view, Trello is wonderful. However, I would give up some of the things I love about Trello for a free and open source tool like Phabricator that can solve many of our problems at once and be maintainable in the long run. Currently Bugzilla, our wikis, and Gerrit are not enough, and they allow too much bullshit in to the mix from community members with conflicting priorities or unhelpful feedback. Being able to ditch paid, proprietary tools for something pleasurable and easy to use that was FOSS would make me very happy, though I realize the combination of those things (free, beautiful, easy to use) is rare. It seems to me that Phabricator is the only possibility for something that is FOSS and which could give us very usable project management tools tightly coupled with code review and bug tracking. Steven Walling (WMF) • talk 20:41, 28 January 2014 (UTC)Reply

Antoine "hashar" Musso (talk)

Technical activities

What are the main technical activities you're involved in in the Wikimedia community?

Leading CI and maintaing beta cluster. I am a member of mwcore team which maintains MediaWiki on Wikimedia cluster. My main interactions are with:

other developers for test failures, adding new jenkins jobs and maintaining beta cluster
community / developers to deploy configuration change on the production cluster / help in diagnosis
ops to maintain the CI / Beta infrastructure (via Gerrit / Puppet and RT).

Workflow

Fill a bug or it did not happen. I am terrible at managing my emails cause I often forget about them or loose them in my inbox. I make a point to have everything tracked in Bugzilla: bugs, features and tasks even if I have to pester people to make it happen.

Typical day is:

review email inbox, asking folks to fill bugs (bugzilla) or ticket (RT). Delete such emails
read ALL Gerrit notifications. They are either changes I proposed, people asking me to review or follow up on ongoing change. Act in Gerrit to reply / vote / merge then delete related email. I keep some email notifications in my inbox and mark them with priority (todo, important, need follow up …). My Gerrit inbox is thus a personal task list
read ALL Bugzilla notification. I usually reply on spot whenever I receive a Bugzilla notification, will triage the bug when needed. Delete emails, since I act on bugs there is no need to keep them in my inbox.
read ALL RT ticket. Follow up with ops over IRC, eventually replying on ticket.

I do not use Mingle/Trello. I tried but can't really afford to use yet another tool beside Gerrit and Bugzilla.

RT tickets usually have a counterpart in Bugzilla so I can track RT tickets.

In Bugzilla I have a few search queries (ordered by priority and then severity), the one I use almost on a daily basis are:

list all bugs for Wikimedia > Continuous integration
list all bugs for Wikimedia Labs > deployment-prep (beta)
bugs assigned to me
bugs assigned to me or for which I am CCed too (i.e. bugs for which I have an interest into)

Whenever I have a project, I will create a tracking bug then fill tasks that would block that bug. Bugzilla has a way to display the tree of bugs, an example to get some software (Zuul) upgraded is: https://bugzilla.wikimedia.org/showdependencytree.cgi?id=46354&hide_resolved=0

Must be able to do

List tickets assigned to me
Set priority and severity
Change columns being displayed
Save searches and have them displayed in a toolbar (I hate browser bookmarks)
Dependencies between tasks / bugs
Have private tickets (in Bugzilla we use the Security component which is not ideal but at least let us have private information)
Ability to moderate tickets (Bugzilla lets us hide comments)
Have a unique id for each ticket which is easy to refer to
Receive email notification whenever an action is done on a ticket
Have ticket in unconfirmed state, i.e. pending information from opener/confirmation by other person
Make sure everyone uses the same tools.
Real time notifications other IRC

Would like to be able to do

I would like to be able to reply to an email notification and have it reflected in the interface (like RT or Github issue tracker).
A way to change workflow on a per project basis. Specially have a way to track in which version a bug/task has been released. Workflow would be something like: Unconfirmed -> New -> Assigned -> Committed -> Verified -> Released
Asking to a group for additional review/input and make the bug blocked until that team answered. A use case would be to ask Designer for their input, maybe by creating a sub tasks that is blocked.
Generate a roadmap for the next sprint / week. Ie things I should work on.
Generate a roadmap for last sprint / week. A nice way to know what I have worked on or that my projects have achieved.
Rename severity/priority to Impact and Urgency. Then use a matrix to generate the Priority level. Such a matrix would look like:

	Impact low	Impact high
Severity Low	Not urgent	Normal
Severity High	Normal	Immediate action

Something similar to Launchpad blueprints. Doc: https://help.launchpad.net/Blueprint . Example: https://blueprints.launchpad.net/horizon . The concept is similar to MediaWiki RFC process: one propose a new feature, it is reviewed / approved. Then the blueprint is assigned to a product/project manager or a project leader who creates the sub tasks.
A generated list of code to review using scores such as OpenStack reviews dashboard: http://status.openstack.org/reviews/ Changes pending review are assigned a score depending on their age / project and urgency of the blueprints/bug.
Anything that could help conduct bug triage. Maybe burndown charts, a way to have a bug triaging team.
The possibility to assign a task/bug to a group instead of an individual. Currently in Bugzilla we have to move a task to another component and have no idea whether it is going to be deal by someone.
For third parties / vendor, an easy way to fill a ticket without having to register yet another account.
A way for volunteers having a Wiki account to connect using their Wikipedia credentials.
I would like to be able to fix bugs in the utility (unlike Bugzilla using perl or Gerrit that uses Java).

More information

Note that our continuous integration infrastructure receives information from Gerrit. Whenever something occur in Gerrit, an event is sent to Zuul which let it run jobs and report back to Gerrit. It should be possible to hook Zuul with a new system.
OpenStack is apparently considering moving out of Launchpad (hearsay). They even started a new utility named Storyboard written using the Python Django framework.

Gryllida

Latest comment: 10 years ago6 comments1 person in discussion

Technical activities

What are the main technical activities you're involved in in the Wikimedia community?

gadgets and tools development. Gryllida 08:59, 4 March 2014 (UTC)Reply

Workflow

For each of those activities, can you describe the workflow you're using?

I find what functionality a Wikimedia project needs, either on-wiki or on IRC, by trying to participate and by talking to other contributors. I then develop a gadget or a tool in JS or in Perl. Examples: content translation for all projects (also available as a gadget at test.wikipedia.org), draft review for english wikipedia, a Wikilinker IRC bot. Gryllida 08:59, 4 March 2014 (UTC)Reply

Must be able to do

Using the workflow you've described above, can you tell us everything you must be able to do?

I must be able to get funding for my work on extensions. Gryllida 08:59, 4 March 2014 (UTC)Reply

I must be able to have a place where I can put JS functions for gadgets to re-use, across all projects, a given project type, or across a given language. Gryllida 08:59, 4 March 2014 (UTC)Reply

Would like to be able to do

Similarly, can you tell us everything you would like to be able to do that would make your work easier?

I would like a pony in my user preferences. Gryllida 08:59, 4 March 2014 (UTC)Reply

More information

None added. Gryllida 08:59, 4 March 2014 (UTC)Reply