 se vseč izgleda. To je zelo inštačne napravlje, ker je videl, da je to, ki se vseč zelo, da je to, vseč je vseč vseč prišel, da je vseč tukaj, tukaj, tukaj, fri, tukaj, saturno, tukaj je zelo slim, zelo zelo zelo. Vseč In nič sem. Priživite za recente razlihov, kar kješte božete, kaj trebujte, drugo v 5, 6 razlih, prišliš, da se njenim zelo, je nekaj tega aktivitave tudi, nekaj se, na srnjaju. Tudi je to prej, da je nekaj začal, včasih so, pa je tudi občas, kaj je tega, Zdaj, ki so napotnoza taj dovolj, zato pravdu, nekaj neče pohledaj povihljanja z vsem oto tako, ki se ardilo vjdavajo povihljanje. Sdaj je skrani srog, d сокratnjo trafikta ljudje. Pola na razvej. In juz blješiem povihljanje, 7, danes saturdej in saturdej are really marginal. There is an unexplained peak here of a saturdej activity in 2021, it could very well be the automation peak that we've seen earlier. Ok. Of course, when I call Drupal a professional project, I see Drupal.org users are professional, not the final users, because people writing on the issue queue are those who are here at the Drupal con not just the final users of the clients. Let's move into chart 5, which still gives some interesting insight, and it is the issue created by hour of the UTC. So, London time zone approximately. Again, starting in 2002 and 2021. There is a year where you notice it best, which is probably, again, the ones with many issues here. Here you see that there is very, very low activity in general, but still there is activity in the first hours of the day, like until, say, 6 p.m., 6 a.m., London time. Then it increases a bit, this is Europe waking up at working hours. And then, starting here, which is 2 p.m. in Europe and U.S. working hours, you start seeing many, many more contributions. So, it is well aligned from a certain point onwards to the U.S. working schedule until, say, 10 p.m. European time and end of business U.S. time, and then it becomes low again in the European night. So, what can we infer about the community by this chart? Well, first issues appear around the clock, so this is a truly worldwide community. And there are people working on ruble.org at any hours of the day. But, especially after 2010, U.S. working hours are dominant. And so, technical users seem to be located mostly in the U.S., rather than Europe, or still work on U.S. working schedule. So, final insights that we can take home from this when analysis. Drupal has a professional user base dominated by companies mostly that follow a typical Monday to Friday schedule. And the number of yearly issues has been shrinking in the last 10 or so years. This is not necessarily bad. And as we have discussed, December is low activity, Saturday is Sunday low activity, but Sunday was one of the most active days in the early years. This is the one part. Let's move to the where. Where do I file an issue? What can we get by analyzing issue classifications? Third one, let's see issues by category here. Again, left is 20 years ago, right is more or less now. And these are bugs. These are normalized, so it adds up to 100, actually 1000 every year. So, what you find here is the yearly composition of issues for that year. So, if you see it here at about 500, it means that 50% of those issues were in this category. And this category is bugs. You see bugs that are gradually shrinking from being around 60% to being around 35% in recent years. These category are tasks. And I see it as a very good thing, like you start out at around 10%, but then now about 35% are tasks. So, we have the same amount of bugs and tasks on Drupal.org in recent issue creations. And this is a symptom of a well-organized community, where you don't only put bugs there, but also stuff that you are actually going to work on, and it is open and transparent. Here, you have feature requests, which are, as you see, more or less the same in percentage of the years and about 15% to 20% in all recent years. And the most interesting part is probably support requests. You have only a few support requests at the beginning, as people working on the issues are those actually writing the modules, so they don't need support. And then users come, and you see that support reaches at 30% in 2008, 9, 10. It is around 30%, then gradually it starts decreasing. Not because people do not need Drupal support, but because they try to find answers elsewhere. This is a rather obvious interpretation probably. So they move elsewhere, they ask, stack overflow or any popular sites, and find their answers there. This also explains the decrease, partly the decrease we've seen. Then there are plans that were consistently at around 2% of the issues. Chart 2 is directly here, and it is a multi-step chart where we see where the issues were filed by project over the years. We start 20 years ago, and almost all of them are filed in core and a few famous modules, and a few projects are not appearing by name since they have been unpublished in the meantime. And this is 20 years ago. 15 years ago, we are taking steps of 5 years here. Other projects, most notably views, organic groups, CCK are entering the top 10 in terms of new issues for that specific year. Drupal's popularity is starting to depend on modules. You see here they are getting larger, so core is staying the same, and the other ones are getting larger, so this means they are more frequent. If you go other 5 years in history and reach 2012, we see core still shrinking with respect to the previous analysis, like now views, views Drupal 7, which has its own separate project, is almost as frequent as core itself. The security advisory coverage appears, and other modules are starting to make their appearance. Forward 5 years again, 2017. We have distributions appearing, like OpenSocial and VARBase, that are starting to appear in the top 10. Webform and commerce become very frequent, too, and views and other popular modules and their new issues are now in core because this is after the Drupal 8 release in 2015. Let's see today. Today we have a lot of new projects appearing in the top 10. Automatic updates, project browser, cloud, ECA, block class. They are all new with respect to the 2017 snapshot, and again, this is the future of Drupal. The activity is right now on the Drupal.org issue queues, so they are the most active by one of the many measures of active issues that project that you can find on Drupal.org. So, insight from where. The categories evolve to include not only bug reports and future requests, but tasks and shared plans, and this is good because it means Drupal is taking public commitments. Everything is there for everybody to see. Support requests gradually found their place outside the issue queue, as we discussed, and core is still very frequent, and with the inclusion of views and the rest is, of course, much more frequent now, but contrib modules still have a very significant number of issues. Next, who? Like, who is authoring these issues, and what can we infer from data about issue authors? Well, this is the first chart with issue authors all time. This is the number of issues that the font size is proportional to the number of issues created in overall the all time, the 20 years of Drupal. So, these are the top 20 issue authors in the overall project history. You will find some well-known module and core developers here, but you will also find some community-focused people who are not immediately recognizable as the author of a certain module and still appear here. If you want to see it over time, it may be easier to understand. Let's show it. OK, here you will see them appearing gradually, year over year. So, just to say that not all of them have been around for a lot of time, and actually here you see month by month the issue they created in the issue queue. And you will see people that are still joining right now and when, OK, now we are around the Drupal seven times and start contributing now and we will quickly escalate to the top of this list. So, this is our top 20 issue submitters in the overall history of the project. We are now about six years ago, and you will see some spectacular, OK, here rays of some users who are going up and up and up and up and up in the issue queue. And besides the fun of just watching it, this is the stable situation as of the end of 21, we can infer really something from this. First, just making your way in the Drupal.org issue queue is absolutely feasible. We've seen here people just jumping in and start creating and creating and creating issues. Both are excluded here, of course, until reaching the top position. Second, there is no real dominance by a few individuals or a specific company. This is very good for the project sustainability and community, of course. And, yeah, you will see people who joined as late as six years ago, it's not late, of course, it's people who have been around for quite a while, but they managed to do the top 20 list of 20 years. And there is a nice turnover in top position. You've seen a lot of people going up and down in the top positions, which means the community can manage change successfully. So the final insights on the who part. There are people who open thousands of issues with an average of more than one per day over many years that requires consistency and we are talking about opening an issue, not just a generic action like mentioning someone in comment or doing just a small contribution, but creating real issues. And evolution in taking the lead shows that the community is able to empower newcomers and not blocking them, and there is no domination again by a few individuals or any single company. And let's go to the final part, the what to be meant in a surprise, the sense like what. Audities and gems you found over the issues. So the top three highly discussed issues. Okay, this one is kind of fake since it was meant to give credit to a huge amount of people involved in the multilingual initiative. So basically most of these comments are just credits just to add someone to the issue. So I would exclude this one as there is no real discussion here. And but it has more than 1000 comments. We are including both excluding files or patches. So these are just the comments here. This one is the mostly debated issue allowing profiles to define a base and parent profile. It reached 626 real comments plus patches. And it has a follow up since it had become unsustainable to have it as a Drupal.org issue. So this is one that really grew large because many people were having their say. And the next largest is field translation for field collection with a hefty number of comments again and real comments from real people. Here you can really see debate going on in issues. And just as one extra factoid we have more than 3000 issues that have more than 100 comments that are considerably long to read and check. This includes both again but excludes patches and files. Other interesting stuff all these issues still open. OK, they are this one from June 2003 which advocates not calling it a bug but a problem in our site and terminology changes in general in the Drupal.org site. One from October 2003 to expose the RSS feed in Drupal.org own site feed in a different way. And the real one about contrib is from October 2003 of course related to an obsolete module that is not maintained any longer and like life happens and like in open source there is a comment in January 2006 saying I agree this is already partially implemented not completely done yet but definitely on its way. OK, we can still wait, it was for Drupal 7 so we still have one year of useful time before Drupal 7 is officially dismissed so they could still be in time and again if you go on you will find this kind of stuff. There is also a first inclusivity related issue and it was created in April 2002 and related to terminology for not so fluent English speakers so someone who asked and obtained that Baylon errors should be changed into something easier to understand for non-native English speakers so this is the first time and it was more than 20 years ago that Drupal.org really paid attention to community members and they write not to be native speakers or whatever. And then there is the king of all outliers which is this issue that you will find here. It is a joke issue for a joke module named Vaporware and the first person who entered this room is John who is here and is actually the author of Vaporware so we already had an exchange about that it depends on the bed judgment module of course and it was created in a fake way in 97 but in reality probably around 2011 and it is breaking all starts about issues so if you look at my Python code you will always see me excluding removing 97, remove 97, remove 97 and otherwise you would have seen funny stuff everywhere and still I appreciated it because there is a lot of humor in the Vaporware module that constantly promises this will be fixed in the next release so I assume John will fix the date in the next release of Vaporware for sure. And here we are for the talk itself final insights there are data stories written in the Drupal.org issues and through the Drupal.org API you can get all data needed to get insights on the project community composition, key people and have fun while at it because I would never have seen this gem unless I had tried this analysis technically this is a good display of how Drupal can be a data friendly platform for any kind of big sites so not necessarily Drupal.org itself any site, any data intensive site Further work is surely possible like studying interaction patterns one thing that comes to my mind is indeed looking at what happens in the individual issues and seeing if there are more like one person speaking to themselves and this happened in a few that I could analyze like you open the issue, you provide the patch then you re-roll the patch five times then you put a comment and you are a it's a solo issue as I called it just you are the only person speaking on that issue and abandon to yourself or others that may have interaction between two people like question-answer-question-answer-question-answer and this kind of patterns this would be possible it would be quite intensive with the current API design because again it is meant for massive downloads but where massive downloads are in the dozens of entities not in the millions of entities like this analysis and that's it thank you for attending and I'll be taking any questions if there are any questions here in the room or online, no questions online any questions in the room no? OK thank you it was actually quite fun to go through the issues and leave this on for so you didn't hack the admin password at least we didn't uncover anything because it was about Microsoft Access 97 and supporting the Office 97 in the vaporware module that supported everything by definition of course in the next release even getting more professional that's still a nice community more in the way of being professional but also there is a feature from lookup.net