 All right, you're live. Hello. Welcome, I guess, to the tech talk about the Fabricator and Project Management. So let's see. First of all, I want, well, my name is Kim Jill. I'm working in the engineering community team. And there's some other folks, also fabricator lovers here in the room. We have Andre. I can see also Chase. There's Arthur there and Jill. So I get sooner or later all of us will explain something about this. And if you want to ask questions at any time, you can ask at the Wikimedia office IRC channel. And we'll do our best to reply. So I want to say, first of all, that the basics of what we are going to explain should be documented here in this, oops, I should screencast first. Perhaps that would screen sharing. That would help. Yep. Can you see this Wikipedia? Swimming, yes. So we have this page, mediaweek.org, fabricator slash project management. And this is where we try to document not just what fabricator can do, but also the ways that we are more or less agreeing to use fabricator. The tool itself allows you a lot of flexibility. And we like that flexibility, but we also like to at least offer some defaults and offer some good practices to other developers, other teams, other users. So all of us more or less have similar expectations on how to use this tool. So basically, this is the fabricator homepage. So basically, this is a story of tasks, projects, and also boards. These are the main characters. There's many other things, like, I don't know, notifications, and sprints, and whatnot. But I think for this session, it's good that we focus on these three main concepts. The good thing is that these concepts, we are quite familiar with them, tasks, projects, and even the concept of a board, I guess, is not that unfrequent nowadays anymore. But it's good to mention that fabricator has a very special take on especially on tasks and projects. And I think it's good to just explain it a bit. So first of all, a task, let's take this as an example. The first one I have here in the list. So this is a task. And it has some fields here in the top, some data was assigned, the priority, et cetera, et cetera. Projects, so that's one thing. One task can be assigned to more than one project. There's not a one-to-one relationship. And this is very useful when you want to involve more than one team in a task, as usually happens. It's also useful when you want to tag a task with some attributes, like, I don't know, easy or released media week 124, et cetera. Some tasks are public by default. You can also make them private. And here's the description. And you can edit this description and you can comment. OK, that's the very basics. Everything is a task. So fabricator doesn't make a distinction whether this is a bug or it's a feature request or it's just an idea to discuss. Everything at the end is a task. So whether you're doing a user story or whatever, everything goes with the same format. And basically, it's just by these attributes that then you are going to say, this is a user story. Oh, this is just a bug, et cetera, et cetera. OK, so these things here, projects, these colorful buttons, these other projects. And there's actually one page, a wiki page, fabricator slash creating and renaming projects, where you can see which type of projects we have agreed to have. And we tried to follow these guidelines with colors and icons. So we have projects, like the regular project. We have to do this thing, or we have to maintain this piece of software. And this is what we do. So these are the blue buttons. You'll see lots of them. We have also projects for teams, where the team gets organized. And these are purple. And you can see here some avatars. Anyway, you can see that. Then we also have spring projects, which are supposed to start on a certain date. And then, I don't know, two or four weeks later, they finish. You can also have release type of projects, where you put all the tasks that are supposed to be solved or deployed in a release. And then we have also tags. As I was mentioning, you can tag JavaScript, or you can tag Easy, et cetera. This button we still haven't, we are not using it yet, private, but it's OK. So we have to take into consideration in Fabricator, projects are a bit like tags, and tags are a bit like projects. So you don't basically, let's have a look to a project. For instance, we have here media week extensions flow. And here we see all these tasks that are related with the flow project. Lots of them. Good. So some people, the expectation that we have seen is that people will say, OK, so I have now this project called flow. And then if I can, you can edit the policies of this project. So some people think, OK, so I actually want to have a private project that only some team can, is visible to only some team. And only these people can edit, et cetera, et cetera. So well, it doesn't work like this. Basically in Fabricator, because there's no alignment between tasks and projects, it also happens that the policies are totally independent. So one task can be public or private. And the project that it's related to can be public or private. I'm explaining this because this seems to be a source of confusion. And shouldn't be a problem in our context, because by default, all the tasks are supposed to be public. But just for you to know that when people say, hey, what happens? Everybody can join my project, or everybody can edit my project. This literally refers to this page you can see here, the page of the project. The tasks are completely independent from the policies of the project. So this is more or less the story of tasks and projects. And you can then do many combinations with them. At the same time, tasks have different priorities. So this one has priority high. I'm not going to touch it, but just for you to see. I could set this priority to different levels, and break now, which is stop everything, fix this task. There's also high, normal, low. We have this level for need volunteer, which is a way to explain this team of maintainers is not planning to work on this task anytime soon. So if anybody wants to step in, feel welcome. And then, of course, we have needs triage, which is the default priority for the tasks. This is the default state when they are created. Yeah, so basically these are the elements that you play with with tasks, mostly. You create a task. You set the priority that at the moment this task seems to have. You might see some people or not. You might assign it to someone or to yourself or not. And this is how then the task evolves. And this is then the point where we have another element joining, which have the boards. Let's have a look to the boards. So basically, every project has a board and only one board. So this is the fabricator project. We have some sub-projects here. But every sub-project is a project on its own. And we'll have its own workboard. And well, if I go and check the workboard, you will see you can define the columns you want. Here we have backlog, need discussion, ready to go doing. The idea is that new tasks land here in the backlog. And then you push them to the right as much as you can. And at some point, when the tasks are done, they just disappear. You can set different filters to this workboard. So you can still see the tasks that have been completed grayed out. And well, of course, you can move tasks from one column to the other. I'm not going to mess anything here. But that's basically the point. I think there's basically two types of projects and basically two types of boards, therefore. So this fabricator project is one of those pocket type of projects. So people create new tasks, and they end up here. And we do fix them. But the process is quite continuous and relatively slow, slow in the sense that we are not very obsessed on finishing the 54 tasks we have here in the backlog plus the 32 we have in the need discussion, et cetera. And as you can see, there's plenty of tasks. A different type of project is this sprint type of project. So here you have less tasks, although still quite a lot. But anyway, you have the tasks that you think that you're going to be working on during the sprint. And here things might go a lot faster. So ready to go doing because, for instance, this is the December sprint of the engineering community. And I think these are the basics. Just yesterday, we deployed a specific type of project for sprints, which also brings a burned-down chart. You can define the date, and it has more complexity. But I think it's better to talk about the sprint application specifically in a different session. I think with this, we have already enough to digest. So I don't know if you have any questions at this point. It's a bit to the data, but because there are some tools like Kalmanhap is limited for the doing column, that they can't move more than five classes to that. Yeah, so you can set a limit to the column saying, and actually I've been very tempted of using it in the needs discussion column, for instance. It's like, hey, we're not going to discuss more than 10 tasks. So if you want to discuss any one, we have to decide on one. And teams that work on Scrum, I don't know, Jill or Arthur, I guess teams are putting hard limits sometimes on those columns in terms of how many points you want to handle. So for Scrum, you wouldn't necessarily put hard limits on points per column, but you might have a hard limit on points per sprint. Other ways of managing work, such as Kanban, you might have a hard limit of the number of tasks that might appear in any given column. So it just kind of depends on the specific ways that the team is working and their particular needs. Bottom line, if you want them, you have them. Well, I think it's good if now we move to Andre, and then he can explain a bit of how teams are working on this, and then we can have more conversation about the questions you have. OK, hey, I'm Andre. I'm also trying the screen share now. So I'm just applying to show you some examples. Are you screen sharing me? No, no, OK. No, yeah, it looks like my computer is a bit slow. Well, so as Kim said already, there's different kind of projects. For example, there's this one way to use it, a project as an umbrella, and that's, for example, what Visual Editor does. So in Visual Editor, Visual Editor itself as a project is an umbrella project, and you can see that there are sub projects, like Visual Editor content editable. This is one way to do it. Another way is that there are team umbrellas. This is, for example, the engineering community that we're in. And these ones have either subprojects or sprints. For example, in the engineering community team, we have sprints. Kim already showed, for example, the December one. And what I like on the project page view that you see here, for example, this task here is part of the ECT summer project. And in the ECT, we have monthly projects. So you also see this was already part of the November project, which is in gray here because it's archived. It's like this archived projects that were sprints projects that were in the past. And in this view, it's also pretty useful because you can see, for example, if a task was already part of several sprints, then, yeah, you can realize, OK, things take a bit longer. I'd like to show two more examples. One is the board of the PiWikiBot project, simply to show which kind of columns you have on the work board. On the MediaWiki or Fabricator project management page, we give some examples for columns. For example, need discussion, ready to go, doing. And here you can see the PiWikiBot project. For example, I just want to show the column names. They have the usual backlog as a default. They're doing the planning for the next release here. So you could also, if you wanted to, in your team use a release project for this. But they decided to go for a column. We give you your production labs issues, ready to go, which is the standard. They also use upstream issues here as a column, backwards compatibility, and waiting on other changes. So this is one way to organize things. For waiting on other changes, these changes are, for example, external, like third party projects, where you're also waiting for more input from the reporter, because there's not enough information. We also offer special status, which is called stalled. So that's another option, how you can mark tickets that you currently cannot act on, and that doesn't clutter your list of open tickets by the status. And one more example, how the language engineering team is using the fabricator. This is the task of language engineering. You can see here the projects. There's language engineering as a team. They have it on the backlog. There's a specific code project here, which is a conversation extension in blue. You see there's, I should go here, yeah, the sprint. Sprint 80. That's there, I think, two weekly sprints they have, and they also plan releases. So release number three of the content translation project. And in this case, going to the release board, release three, you see here that in the language engineering team, a release consists of three sprints. So this is a pretty nice way to do it, because they have the backlog, but they also have the sprints here as columns. So sprint 79 is already in the past, sprint 80 and sprint 81. And as these are also projects, they have, for example, for the sprint 80, also their own work board, because one project has one work board, and here you can see usual columns again, like backlog in progress, in review, and some more. So Fabricator gives you quite some ways to work on it, and we document them currently on the project management page. And this is still a little bit, as more and more teams may be made away from other tools, but these are some examples or ideas you can have how to organize your team if you're not yet on Fabricator. That's it, basically, for me. Questions? If there are no more questions, we can explain. So we have seen that the team or the project views, so those boards, those list of tasks by project. So usually what happens is that, well, at some point, you are fine-tuning. So as a person, you get some tasks assigned. You are subscribed to some other tasks, et cetera, et cetera. So you start from the 78,000 tasks that we have in Fabricator, you end up having in your surroundings, hopefully a few hundreds, no more than that, that defines your day-to-day. So what it's very useful to explain is the individual point of view. So for instance, Fabricator has a very powerful tool to define, let me see, where do I have this? So here in Manifest, oh, I should share before. Moment. Yep. So here we are in the, let's go to the homepage. So here you have Manifest, which is a tool to manage tasks. And here you have a set of queries that it changed from user to user. Some of them are common. All of us, we have them, like open tasks, authored, et cetera. But basically, you can create your own search queries. You have here 1,000 parameters, probably everything you need, almost. And then every search query then, for instance, as default, I have assigned. And this is the first list I see every morning, or I try to. And this is what gives you, this is pretty obvious. It gives you these other tasks assigned to me. With the priority levels, you can sort them in many different ways. But then I think depending on your role in the project, or in the different projects that you might be involved, then you might want to have other queries just adapted to that. For instance, I have here Triage Fabricator. And this is a list that actually, if I show you what I have here, this list is tasks in the fabricator projects, but only show me the ones that are unassigned. So if it's assigned, I'm trusting that whoever has assigned it will deal with it. Show me only open, so the stalled ones, I don't see them, and grouped by priority, and sorted by the date that they have been updated. And this provides this query. And actually, oh, sorry, this one. And actually some days, so normal day I would just go through this starting from the top. But actually some days I feel more like in pure Triage mode. And actually what I do is I go to the bottom of the queues, and then I look at the tasks that have been idling for a longer time without a single update. And then I look here and I see, well, maybe this is not so normal, maybe it's more low priority, or hey, we didn't finish this discussion, and it's been now three weeks. So that would be one example. And basically here you can have all the queries you want to have. And by editing these queries, you can just define which is a default. You can sort them up and down. So this is a less obvious feature compared to boards. But actually I think that as your mileage increases in fabricator, probably also the more you use queries like this for your own work, and then the boards become more something of a common playground, it's more the project level view. I don't know if this is the experience of other people here in this session, but at least I've seen it myself that I'm putting more time in my customized queries and less time in the generic boards in general. Do you want to add something, Chase or Arthur or Jill, based on your experience working with fabricator? I guess the only thing that I'd like to add is that one of the things, Kim, you already touched on this a little bit, one of the things that has been probably the most difficult for me to wrap my head around, and that is going to be one of the biggest changes from most of the other project management tools out there, is that a task can have a one to many relationship to projects. Meaning, as Kim mentioned before, you have a task that can exist simultaneously in any number of different projects inside a fabricator. And I think one of the big challenges that this raises is issues around how do we manage maintaining the status of a task or a given priority of a task. So it's important to spend some time reviewing the project management page on mediawiki.org, where we've started to outline some of the guidelines for how we can manage this stuff. But I think overall the most important thing is to be very respectful and mindful of the fact that this task might exist in other projects that might be projects that are not managed or maintained by the particular team that you might be working on, whoever you might be. And if in the event that a task already has an assignee on it, it's probably best to leave it up to that assignee or that assignee's team to be able to manage the setting of the status or the specific priority of the task. And I think for folks who might have concerns around the ability for people outside of a particular team to mess with the statuses and the assignees and the priorities of tasks, I've heard that there are some ways that we might be able to lock a task down to protect it in the event that maybe there's some sort of real war going on of multiple people arguing over setting priorities and stuff. I don't particularly personally have a very good understanding of how that works. Kim or Andre, would one of you mind talking a little bit about that? Andre, you or me? Yeah, I think we currently, for example, we cannot currently lock down the priority field if a task or a status field. If a task is part of a certain sprint project, I'm aware that there's a request about this, but I don't think there has any work been going on already. It's definitely something we have to investigate. That's what I'm aware of currently. Yeah, so the current situation is either you have public tasks that everybody can edit, or then you have private tasks that most people cannot even see. But already today, if there would be a big mess around a task for some reason, you could contact administrators, and every task has their own policies. So a task could be blocked for editing, for instance, or just Arthur and his friends can edit this task, or things like that. We have a flexibility, but today would be more like an emergency type of action, not something that we would have a process for forever. I could maybe clear up a little bit why that is. So just like everything else, policies within Fabricator are task-centric, even though projects are their own policies, so do pace, so do files. But the mechanism in which to tweak who can adjust policies is a giant hammer in that it's entirely global. And because we're using the policy mechanism to hide security issues, and also we're using it to hide operational issues that we're importing from RT, right now it's locked out basically to Fabricator administrators and members of operations and members of security. Now, hopefully the fix for that is because it being a global thing makes it more complicated, the big fix upstream has been working on for a while is to come up with this JIRA-like spaces idea where there would be containers within Fabricator, and so like the design team would have space and theoretically within that you would be able to assign or piecemeal out policy rights or whatever. But for the moment they're global throughout, and since we have things that we need to hide, legitimately, policy has been restricted to basically teams that deal almost strictly in policy oriented tasks. The side note to that is we made kind of a custom mechanism so that anybody could at least affect the policy on a task to make it private and or hidden. And so if you go to a task you'll see a security field and there's a drop down which basically applies a macro or a template of settings that can file a task as a security task and affect the policy and all that without actually having the direct ability to manipulate it. So that's why the abstraction exists now. It can't be kind of piecemealed out effectively for what I think you're asking or want to do, but upstream is definitely aware of it and it's kind of a big thing that's been on the radar for a while. So there's this idea that Andreas mentioned before that I am not even proposing. I'm passing it on. I think there's something good in it, which would be this idea that optionally tasks belonging to a certain sprint or to sprints in general, those tasks that would have a minimum level of protection. So this topic seems to stress a bit, product owners and similar people, so people that spend a lot of time with the board and they really fear the day that they wake up in the morning, they just log in and someone during the night has been messing completely the whole board. This hasn't happened, nothing close to that, but I understand that there's one of those things that I don't know, that concerns people. So one possibility, but I said this is the task 819 in case anybody wants to join and discuss where there will be this idea. So by default, all tasks are public, editable and everything, but when a task is selected for to be part of a sprint, then for instance, the board of that sprint could be only, you know, only the members of that sprint could move the cards, for instance, in that work board. That would be one idea. But as said, we are just at the beginnings of Fabricator in Wikimedia and sometimes we are mixing here two cultures that are very different. In one side we have the Wikibase culture where people, the same people that are saying, oh, but now in Fabricator, everybody can says that is a member of my project or everybody can edit anything in my project as well, yes, at the same time in Wikidotork, they can also do anything they want in your project page and guess what? In the last years, nobody did because people have better things to do than that. So we have this super open culture in one side and then we have also, at the same time, the culture of teams coming from Mingle or Trello where they have control over every single pixel there and they say, wait, wait, wait, wait, wait a minute. Are you saying that anybody can just come and touch my task or touch my board, wait a minute? And well, all of us, we are meeting now in a single place and we basically have to find the balances for these very different expectations. So everybody's happy and the whole thing works. Probably good to note that the board priorities or security settings policies are affected by the project policies, which I believe project owners can set. It's only the task policies themselves which are currently restricted. Yeah, there's a way, we have to discuss. Okay, are there any more questions, more comments? Anything from IRC, Rachel? Not yet, I just asked again. It's fine. So it's not that we are not getting questions during the day, so it's fine if now we are not getting, and in any case, I want to remind that we have this project management page in midamikido.org. For those that are really starting with Fabricator, there's also Fabricator slash help, which of course covers the very basics of how to create a task or how to assign someone to a task, et cetera, et cetera. So yes, there's already a good amount of documentation. We hope it's useful. And if not, then in the own wiki pages, you can ask. Well, it's easy to find us, really. For instance, on IRC, we are always in the wiki media dash deaf tools channel. And well, as obviously if you post the wiki tech or actually anywhere, someone with some knowledge of Fabricator Pro will come to you and reply kindly. Kim, something from IRC is, Robla says, one thing about the control bit. I think Jan's comment on P819 is a good one. We need master avert tools. And then the DJ says, oh, search, are we planning to approve that? So what are the two things? Okay, so the first one, master avert, yes, nice feature. Doesn't exist. I don't know, Chase, if you can figure out what would it take to have something similar to go back to this point of history for this project or something like that. Okay, so obviously this is one of those things where if it isn't just baked in from the absolute get go, it's really difficult and or virtually impossible to do well. They keep transaction, I don't know. I mean, it doesn't really exist in the manner in which people are kind of talking about it now. And I don't know if Upstream has a serious interest in doing it, but one of their core philosophies is actually somewhat aligned in that they generally don't destroy data. So if you go in and you edit a comment, it gets created underneath the covers as just another comment transaction aligned with the original transaction had the original comment. So if you make seven edits, they're storing the entire history of it and it's not necessarily displayed, even for administrators actually. But in general, they don't allow destroying data through the UI at all. So, and also if you go through and you were to edit like the description on a project or something, you'd see a little thing or a description on a task. I mean, you'd see a little event line that said, hey, this was edited and you would even show you a diff. And kind of what makes that possible is that they're storing the full history. But the tools that actually revert them automatically don't exist. I don't think that Upstream will probably create them. And for us, it would be a pick and choose what the really important things to worry about are because it's gonna be an awful lot of work to try to do it right. Yes, yes. So so far, the measures that we are taking are the preventive ones are, for instance, some of the features we are limiting those features to a set of, to a team basically. And it's a team that if you are around working, et cetera, it's not difficult to join. Like for instance, we have this feature for batch edits and in order for you to get batch edits, you only need to know someone that is in that group, that in the triagers group that you know or that you can basically convince, hey, you know, I'm a good person, just give me those permission. Let me join the teams so I get this permission. So it's very easy. And also, for instance, task create, project creation, same thing, there's a project that you need to join. And when you join that project, then you can create other projects. So for an average user, today they cannot create projects, they cannot batch edit tasks automatically. This limits a bit the possibilities of messing around, but still, of course, someone with determination can mess around in a lot. But A, as Chey says, no data is destroyed. And I think another area where we are going to be working when we have a chance is an upstream is more interested in looking at this, is in limiting or throttling activities when they start to look suspicious. Or of course, putting more trust on users that have been more on, I mean, Wikimedia also does something like that, no? When I just join with my new account, there's still some things that I cannot do. My edits are not patrol, auto-patrolled, and until I have five edits, there's some things I cannot do, et cetera, et cetera. So I think that in general, the trend is going to be more in this direction of just trying to understand the level of trust that the user has, and then have the possibilities, give the more trusted users more power basically, which is what, in the context of Media Week itself, is what we're also doing. And sorry, that was the second question. Yep, sorry. It was from the DJ, and it was search, are we planning to improve that? And then I have another question afterwards. Okay. Search. Well, the good news is that, yes. So actually, Chad, this week, has started putting time on this, and he already contributed that patch upstream to bring us stemming, which means that if you write a house, you would still find houses, and these type of examples, not just the literal word, but other words. So we have this task, I don't remember the number now, but we have this task that tries to collect all the search-related problems, and yes, the good thing is that the backend we have is based on Elasticsearch, and Elasticsearch is also the backend that is now powering searches in, well, everywhere almost, I don't know, these days, in Wikimedia. So both Chad and Nick can give a hand from time to time on issues that we have at that level. And also upstream, they are also interested in improving search, and they are looking forward for specific problems. So we are trying to define what are specifically the problems. But yes, the generic task about improving the Wikimedia search is high priority, and yeah, we hope to have better results soon. Andres says, task 75854, 75854. All right, so Rabla have the question, we've had mass vandalism on Bugzilla in the past, we will almost certainly have it in the future on Fabrikator, so we need to be ready for that day. If there are tracking requests for that, and Chase has been answering that a bit on IRC, but it might be good to answer it here as well. There is T84, which is a general task on keeping vandalism handled, let's say, like this. When it comes to Bugzilla, Wikimedia Bugzilla initially had this policy that all users had quite some rights. For example, EditBugs, which was a specific permission in Bugzilla, which allowed mass editing tasks. And as we have currently restricted mass editing in Fabrikator to the tree address group, and you have to join that group, and as to make you a member of it, I consider it less likely. But as we said before, we currently don't have real tools to mass-revert some changes. It's way less likely that some mass changes happen by mass editing, but we would still have to go via SQL to run a query of all the things that this user did in the past if we want to go that way. But that should be too hard, however, so. So preventing vandalism, it's in my very short list of priorities. The only thing that it surpassed by two areas and maybe a third one. So one is security. We still are nailing down the cases for security. And the second is search. And this doesn't even count the RT migration that we still have to do, and we are going to do next week. So yes, it is important, but there's still a lot of things that are more urgent slash important today. But I agree, I don't want to be in that day when we just wake up and see that there's a mess that we have to undo. But that's what we have today, the resources we have. Andrew Russell Green wants to know about Fabrikator Mylan integration. Which integration? Mylan, MYLYN integration, but he sees that it's only an upstream wish list. I think whining, if I understood correctly. Sorry, my pronunciation wasn't that good either. Mylan? Whining, right? I should probably see and then take a quick look myself. Mylan, it's spelled now in the... Mylan, that's something from Eclipse, if I remember correctly. No idea. I don't think there's any integration available currently. Yeah, but that would really be something for upstream, I guess, when it comes to integrating with these tools. Any more questions? Well, I don't know. Should we wrap up? Do we wait a bit? Yeah, that's great. Thanks for coming. Anything to add before I stop the podcast? Or if it's not the podcast that's hanging out? See you in Fabrikator.