1162:@Okeyes: I understand the decision isn't under your control, and that the earth's core will be ice rather than iron before the decision changes. But why would you expect me or anyone to waste my time giving input again, when the community's clear input on this matter has already been ignored? The interface tweaks are not going to solve the problem, but they're what WMF decided to do, and so regardless of community input, that's apparently what we get. We see a report saying that there's a disconnect between editors and WMF, and well, for a lot of us (certainly for me), that issue and others like it were the reason why. This is ultimately WMF's project, and they certainly have the ability to ignore any consensus of the community they like, but they shouldn't disenfranchise the community and then wander around wondering why the community feels disenfranchised and why more editors leave all the time. If you'd rather not hear that, no one's making you listen to it. No one has thus far.
954:
will be effective at doing so if it has a good signal-to-noise ratio. And the developers, led primarily by the WMF staff, need to provide a realistic evaluation of how viable and what priority an approved request is, and what progress is made towards realising it. The emphasis, from both sides, is on "realistic"; as I've said before elsewhere enwiki needs to have a realistic view of how much time it is 'entitled' to (none at all from the volunteer developers, and not as much from the staff developers as it generally tends to expect). But as you say, having a clearer picture of how the relationship works will allow both sides to better prioritise their contributions, and hopefully help the interaction produce less heat and more light.
639:
sysadmins, operate on a very different decision-making model and have relatively little experience of how the consensus model works. Decision-making amongst developers is much more hierarchical; there are a whole tier of senior developers whose opinion simply matters more than that of more junior devs; and of course amongst the paid staff and sysadmins the hierarchy is even clearer. When communicating with developers, they're not looking for a consensus they can judge, they're looking for a clear statement of what to do from someone who has the authority to speak on behalf of the editor community when doing so. Of course in judging
660:-esque panel responsible for judging the consensus for shell requests and reporting them, and no other changes should be considered" or "all changes must be proposed and requested by ArbCom", the sysadmins would be delighted to have that clarity. But when 600 editors can't demonstrate a consensus for a FlaggedRevs configuration, and someone proudly presents a "consensus" of 20 editors which is then thrown back in the sysadmins' face, you can't blame the sysadmins for concluding that enwiki Simply Doesn't Know What It Wants. And in that case, why should they waste volunteered or paid-for-by-donations time trying to work it out?
408:(which clearly defines what the programmers must build, and provides a basis for building test cases). While venues such as the Village Pump allow high-level requirements to be suggested and debated, I've always felt that the project's editors have been marginalised from the important task of creating functional specifications. Of course, the programmers must be involved at all levels as they are after all editors, and must assist to keep the specifications technically realistic. The construction of detailed specifications
104:
been put out to discussion and even a vote? I'm sure there are lots of other software-related matters affecting daily editing that the community of editors is well-placed to work through given the chance. But that would need a more systemic, client-focused approach to the relationship, in which options, projected budgets, and timelines are explicitly set out, and in which there's regular reporting on progress and hurdles (in layperson's language as well as tech-speakāpossibly via this
370:(responding to no-one in particular) I actually used the phrase "user-developer divide" (or indeed referred to "users" at all) once in the whole article, in the poll caption, in order to avoid excluding any potential readers who don't edit from answering the poll. The focus of the main story is clearly open to questions of insider-outsider mentalities between editors and users (potential new editors), which I made reference to during it. I've updated the subtitle on the main story. -
764:, it is clear that the brokenness of our SVG renderer causes immense trouble to editors, and sub-standard output to users, with problems known about for at least seven years that could be cured by switching to a different back-end renderer, yet central interest seems always to be exclusively focussed on whatever pretty new bauble somebody's dreamed up, rather than nuts-and-bolts technical issues like this that directly affect the quality of the output that WP can serve up.
937:
people employed by the WMF. The "sysadmins" are responsible for 'operations' (maintenance of the cluster hardware and software) and for deploying configuration changes; with I think only one volunteer exception, these are all staff. The issue Jheald raises above with GeoHack has nothing to do with either of these groups, but is with a
Toolserver user; who are a separate (volunteer) group again who are very much a law unto themselves.
824:
editors when it comes to herding them. I would expect it to be easier to focus the paid developers with the help of the
Wikimedia foundation, but I suspect that to many of the board members Knowledge (XXG) (especially the English language Knowledge (XXG)) is no longer a shiny new toy, and thus not of much interest. Of course it could also be that they find the community here to be incredibly difficult to work with, and I sympathize.
29:
859:
that float some way up to higher priority. So we need a noticeboard or some other forum on en.WP where editors can suggest improvements, the technicians can use their expertise to dampen or encourage expectations where indicated, and the community can discuss and !vote on how suggestions can be prioritised in the light of perceived importance, technical feasibility, relative cost, and other technical opinion.
100:." But aside from the upload wizard on Commons, there's been a glaring failure to resolve the big issues; several significant projects almost got there, I'm told, only to be left by the roadside for the next set of goals. For example, the new editing interface looks sound in principle, but I'm not holding my breath this time, and it would be nice to see a bit more of what's going on behind closed doors.
635:. Fine, no problem; a quarter or so of the rest of WMF's editor community is able to communicate efficiently with the developers and sysadmins and are perfectly happy with the system. Why should the sysadmins spend so much time and energy dealing with grumpy, cantankerous enwiki, when the other wikis are so much easier to work with?
591:. Maybe we need better ways to communicate, but it's really difficult to do so with every single community we need to support (we'd need to track hundreds of talk pages on hundreds of projects - we can't do this). Ideally the communication would occur in one place, where the projects are being managed (currently mediawiki.org). --
1256:
call to quash clear en.WP community consensus on the need for autoconfirmation before one can create articles? It required a minor technical change. So why does that morph into that kind of policy power in defiance of the community? By contrast, when I gained overwhelming en.WP community consensus to
1106:
The reason we don't have such a system on enwiki is very simple: because no one has made it yet. As Jarry says, Raymond is a German-speaking editor and occasional volunteer developer who devotes time and effort to compiling that noticeboard, and the rest of the developer community and tech staff are
885:
Whether it's feedback on features or contributions of code, the process of triaging, responding to, or acting upon any kind of community contribution should be an open one ā and we need to actively work to grow communities of volunteer responders, liaisons, code reviewers, and so on. If we become the
862:
Without structured community liaison by a technical department whose employees seem to be out of touch with the demands of regular editing, technicians will gravitate towards strategies that produce only patchy improvements to the basics, plus blue-sky toys of marginal utility. We have ample evidence
755:
What worries me is less the management of new feature and tool creation, which seems to dominate almost all discussion and mindshare; but rather the apparent almost total lack of resources and management given to existing features which fall short, even when they impact directly on user -- and reader
579:
I'm fine with being called dismissive of the idea that we should be developing specifically to the community's specs. It's been proven that it doesn't work. FlaggedRevs took years, went through numerous total redesigns, and as such is a very difficult piece of software to use, configure, and develop.
542:
Happy-Melon, for example, talks of "the horrific technological inertia that is developing within the community". Excuse me? He continues in a frame that is almost a threat (and note the irritable "bothering"): " is only going to lead to two possible outcomes ... Either the developers abandon any hope
501:
okay at the (programmer's) time, but was overwhelmingly rejected when put to the community (after years of debate). Programmers are not necessarily experts in any of the requirements they are implementing, so it is not appropriate that business-related decisions could be left up to them (often at the
275:
the bosses of the "developers". That seems to be a common misconception: that the editor community says "jump" and the developer community asks "how high?" The developer community ā both paid staff and volunteer ā is not a collection of serfs." I'd be hoping for something less adversarial than this
70:
There's a major question-mark about how the tech side is managed and what relationship it should have with the community. Software development is normally subject to a contract between producer and client; from that central fact emerges the decision-making, the planning, and the timeline for building
1194:
before it's deployed, and why you have someone to directly tell you're disappointed. But without feedback on what would make it better and a way forward, the sad fact is it isn't going to make much difference, because we can't infer improvements from "I don't like it". I understand if you don't want
983:
A lot of these issues are bottlenecked on operations. Until very recently we've had basically no employees. We're making great strides in catching up with the technical debt that's been collecting over the years. Also, we're putting a lot of effort into scaling our operations by opening it up to the
953:
Pretty much everything else I agree with. I think enwiki needs a separate noticeboard purely for discussing software changes, and a clear procedure for managing, triaging and evaluating discussions there. The developer community needs to engage with that noticeboard; I'm pretty confident that they
847:
sympathise: the technicians and the foundation have made little attempt to develop effective processes for engaging with the community on the technical needs of editing. Instead, the professional salaried technicians we pay resort to defeatist and self-serving mantras about how the community gives a
727:
page where a prototype can be tested, however the section under "User requirements:" is empty. Now I know that no one is going to suggest that there exists a development methodology that shouldn't have requirements (Agile included), so could someone please add something (including links) under "User
298:
I think you're taking a different discussion out of context to try to make some point here, which I'm not sure is correct, and my comments there don't support your argument. You seem to be willfully conflating 499.9 million readers with 90k editors, calling them "users", and implying that both have
1047:
project. I appreciate that it isn't what some people want (by which I mean "it isn't ACTRIAL") but it is, speaking as a patroller, much better than what we currently have. We can sit here and debate a decision made close to a year ago, a decision that isn't going to change, or we can go "okay, so X
1009:
I rather lost faith in the developers having any meaningful engagement with the community when the community came to a consensus to restrict new article creation to autoconfirmed users, duly filed a bug citing the discussion (which, unusually for such a major proposal, came to a very clear result),
898:
While the tech department is in Europe at our expense attending the
Hackathon, they might think carefully about the need to get more serious about the workaday stuff like maintenance codingālike clearing the backlog of thousands of items and working on the improvement of existing functionalities on
681:
is interested in seeing the requirements building and functional specs that the WMF is working on, they are all on public wikis and are editable -- though I wouldn't follow BRD, rather, discuss first if it's not minor. If you want to comment on and help build requirements, your help is most welcome
557:
The blame-the-editors line continued with Ryan lane: "writing specs is almost always a terrible, terrible idea ... design by committee doesn't work ... incredibly bloated". No self-examination of how our salaried technicians might engage more productively with the community? Why bother: it's always
463:
I'm just going to mention two extensions, and we can discuss why the community writing specs is almost always a terrible, terrible idea: FlaggedRevs and LiquidThreads. FlaggedRevs is the poster child for how design by committee does not work in software. Go back and read the background on that. The
167:
So why confuse the issue? "User" is a set of people who contain all people who use the encyclopedia. That's 500 million people. Of them, we then classify 499,910 of them as "readers" and 90,000 as "editors". This discussion is about "developers and editors", not "developers and readers". Please
132:
You are not discussing a "user-developer" divide. You are discussing an "editor-developer" divide. There are 500 million users and 90,000 editors. Users don't care about watchlist bolding or anything along those lines. Editors do. The changes to the headline are misleading; I'd change that back
1189:
or any of the other editors who have been knee-deep on giving us feedback on the
Article Feedback Tool or New Pages Feed. We, or at least I, am listening. One of the reasons I was hired was to try and help rebuild the bridge between the community and the foundation, and that's why we've been doing
415:
WP has a wide variety of editors: some of whom will suggest changes to the software, and many of whom will get involved with a consensus-driven approach to figuring out a good set of functional requirements. I know that figuring out the process (by which good consensus-driven specifications can be
103:
Should the community have a formal say in the tech programs, particularly through an open and inclusive system for prioritising needs on the basis of professional estimates of costs and feasibility? If we're going to talk little things, when has revamping the table and maths-notation syntaxes ever
936:
The situation is massively complicated by the fact that there are numerous different groups at play here which are often confused but are in fact very diverse. The "developers" are the people who write MediaWiki core code and extensions; the majority are volunteers but there is a large cohort of
858:
Nothing can be done without connecting the dotted lines between (a) the resources the foundation is prepared to allocate to a set of community-prioritised projects over each set time-interval, (b) professional initial estimates of the timeframe and labour-hours required for the candidate projects
801:
UK National Grid co-ordinate reference we output is wrong; every map service we link to that uses them points to the wrong place; and every user that tries to add coords using those services may give up because WP won't point to the right place. I suppose it's all considered less important than
638:
Of course you'd (rightly) say that
FlaggedRevs never developed an adequate consensus on enwiki, and the problems that highlights with our consensus model are independent of the editor-developer relationship; and that's partly true. But remember that the developer community, and particularly the
550:
Among those technicians, Jorm, above, has chosen to employ a bossy demeanour, point-blank refusing to discuss the substantive issues until the journalist accedes to his demand that "user" be changed to "editor" in the article. He's got his way on the semantics, but we've heard nothing more from
940:
While I fervently support the right of all of those volunteers to work on whatever they choose to donate their time to, I've felt for years that the
Foundation should be devoting more of its paid programmer resources towards bugfixes and less towards "blue-sky" projects. But that's a somewhat
823:
I am not surprised that it is hard to get volunteer developers to work on fixing problems with existing features rather than on new features. SW engineers ALWAYS prefer new feature development to maintenance coding. It should be no surprise that volunteer developers are as catlike as volunteer
630:
certainly a substantial problem with the way the two communities communicate. FlaggedRevs is the archetypal example not just for its design process but also its social implementation. Designed by the communities, for the communities; yet four years later this community (which was amongst the
74:
But rather than software producer for the community-as-client, perhaps the foundation sees itself as providing for a user base without their input during the process, like the
Facebook/Yahoo commercial model? This might explain why the tech side seems to be left to its own devices, relatively
949:
and UploadWizard are examples of big projects that have gone much more 'right'. And regardless, the editor community needs to build communications with the developers as a whole community, if they want to have any influence in shaping the overall structure of MediaWiki rather than just the
1173:
I listen to things all the timeĀ :). It's not "interface tweaks"; it's an entirely new setup with much more metadata, many more filtering options and a built-in twinkle-esque system that includes a tutorial for new patrollers. I appreciate it might not look too impressive now; it's still a
854:
procedures for honing diverse opinions into priorities for action, by successively pruning a billion ideas into a manageable number based on iterative back-and-forths by a team of technicians and, possibly, a few elected editorial reps. It makes sense for this to happen in batches, to
646:
Rather, it is up to the community to establish a process by which they can 'decide' to make a change (in our case, discussion-based consensus, for dewiki a much more vote-based poll, and for some wikis an absolute straight vote; this is in place), establish a procedure for agreeing
502:
time of coding) that should previously have been decided by community consensus. I don't believe it would be the most difficult problem in the world for
Knowledge (XXG) to borrow/develop/adapt a methodology that documents the functionals of a proposed development (e.g. some form of
419:
Please note that I admire and respect the work of WP's programmers and don't intend any of the above as an attack on their commitment and hard work. More than ever, WP needs their dedicationāonly hopefully (in our more mature WP), that dedication will be driven by the needs of the
71:
and refining. Since the whole WMF enterprise rests on the backs of gigantic amounts of skilled volunteer labour, it's a wonder the community isn't regarded as a client in a more standard model, closer to best-practice tech development in the corporate and government sectors.
1010:
and got a middle finger and a "Nah, would rather not" from the devs. If that's the type of "support" we can expect, I think any attempt at engaging the developers is relatively pointless, since they're pretty clearly going to do as they will regardless of what anyone thinks.
482:
links that give more detailed examples, I'll be happy to read further). On the contrary, flagged revisions has been adopted on at least 16 wikis around the world, and the concept's evolution (Pending
Changes) is making a resurgence (with at least 63% support in a current
1174:
half-finished prototype, but I wanted to push it out to enwiki as soon as possible because (quite frankly) I'm tired of seeing projects where the devs fling it on a temporary prototype server nobody is familiar with and are suprised when they don't get any feedback.
434:"the project's editors have been marginalised from the important task of creating functional specifications" = "the project's editors have marginalised themselves from the important task of creating functional specifications"? (Just playing devil's advocate here) -
1042:
The final decision was made by Erik, the Deputy
Director, not the developers. On community engagement - I've spent the last six months doing community engagement. I've spent the last four of those months doing community engagement on precisely this issue with the
392:(As background: I've been in the IT industry for over two decades and have written a large amount of code for both large and small organisations; and I've also created a number of functional requirements documents that have led to successful software development.)
631:
loudest voices calling for the implementation) can't make up its mind on deploying it (can't, it seems, even make up its mind about how to make up its mind), and seems on the verge of discarding thousands of hours and tens of thousands of dollars worth of work
385:
The substantive issue that Tony1 raises is important, and has needed addressing for some time. As always, WP has entrusted its editors to make decisions on behalf of its readers, and accordingly WP's editors should be the driving force for all software changes
899:
the basis of effective negotiations with the community. A better-oiled process for liaising with the other language WPs might be possible after we get it right on en.WP; and let's not forget the 30,000 or so registered users of the wiki software elsewhere.
1257:
boost the default thumbnail size by almost 50%, the technicians properly advised and held off for logistical and technical reasons (for about six months). And if there had been technical reasons not to do it at all, one would have respected their opinion.
509:
Anyhow, nothing is going to be solved here; but I'm very willing to throw my hat in the ring if/when the time comes for Knowledge (XXG) to move to a more professional and mature way of handling (at least the beginning of) the software engineering
1107:
happy to engage with that project as much as possible. A couple of people have tried to invest a similar sort of energy and time on enwiki, but have usually had it thrown back in their face by editors taking a shotgun to the messenger.
655:
what should be considered a change "wanted by enwiki"; if enwiki saw fit to create one, whether that be "all changes must be endorsed by 20 editors in an RfC closed by an impartial admin and reported by anyone to bugzilla", "there is a
270:
users in any normal sense of the software development/technical process. I've just visited your talk page to find this statement to one of our editors: "... the primary thing that can be done is to understand that the "editors" are
1124:
This should be a top priority, H-M; thanks for this information. If I weren't a tech-dummy I'd think of running (or co-running) such a noticeboard. But I'm quite willing to ping those who tried, to encourage them to try again.
464:
idea of LiquidThreads is awesome, but the spec was incredibly bloated. Also, the software design approach you are describing is waterfall, is it not? Waterfall techniques have high failure rates and lead to bloated software. --
808:
Despite WP's multimillion dollar income, there simply appears to be no management or resourcing to fix issues of basic functionality, that affect directly the quality and even basic accuracy of what we serve our end readers.
202:
Well, it appears to have been your edit that made the change. If you were directed to make this change, I apologize for implying that it was your decision. Either way: my point stands. I'll take this up with
643:
they can and do note the structure of the wiki involved; but it is not the developers' or sysadmins' role to either judge consensus for a change, or to judge whether an admin has correctly judged the consensus.
342:
I'd be willing to respond to substantive points when the headline is not biased, I think. It's difficult to want to engage in conversation when it appears, via headline, that the outcome is already decided.--
221:. Jarry had already used "user" twice in the text, including in the caption of the poll results. The original "developer divide" raised the question of "divide between what or whom?" It needed to be fixed.
786:
782:
303:
have a voice, and should not be included in the calculation of any "developer vs. anyone else" divide. Say what you will about the developers (both volunteer and Foundation staff) and tensions with the
34:
28:
651:, and establish a procedure for communicating that decision to the developers. Enwiki is substantially lacking in both of the latter two areas. Currently there is no policy or procedure explaining
356:
But just a quick point: the definition of the word "user" is very much at issue here. One must understand that the development teams serves the whole "500 million", and not exclusively the 90k.--
690:
and analysis. (Specifications are not on English Knowledge (XXG) because there are hundreds of wikis to serve with MediaWiki development.) In particular, editors are probably interested in the
535:
What surprises me is the dismissiveness, negativity, and barely concealed hostility expressed by technicians towards editors, and by proxy towards all users. At the very least, it's
79:
490:
Understanding the requirements and documenting the functionals is the only realistic way of producing software that can effect 500 million users (not to mention 90,000 editors).
484:
769:
Or to take another example, a particular personal sore point, consider the bug that means every UK geographical grid co-ordinate served by GeoHack is 200 metres out. So, as
584:. Please read that article; here's a choice quote: "One maxim is that a camel is a horse designed by committee." Also, we don't do waterfall style development. We do agile.
863:
of this misallocation just above, and there's much much more I'm sure editors will document here if asked: basic functionalities have been allowed to rot for years.
52:
Just to note that across the next 2ā3 weeks, it may not be possible for me to put out a full Tech Report. If others want to chip in though, that would be coolĀ :) -
276:
us-and-them frame. The key to the foundation's technical process is that users fall into at least two categories. No one's pretending to be "boss", by the way.
619:
quoted) is not a threat, as there is nothing there that I personally am going to 'inflict' upon the enwiki community if they don't change their ways; but it
322:
Jorm, perhaps you're willing to respond to the substantive points in the article and in my comments here, rather than arguing about the semantics of "user".
554:
In this environment, Jarry seems to have taken to doing the technicians' bidding for them: "the project's editors have marginalised themselves", he says.
111:
A close, trusting producerāclient interaction is always a bit messy and difficult, but it's the only way to get things done in industry and government.
1097:
de.wp has that because Raymond makes it happen; no-one has yet volunteered to recreate the same thing here (although I do follow that page myself). -
17:
547:
speaking as a volunteer, I suppose, so he's on less wobbly moral ground when venting; but the foundation employs a whole technical department.
1048:
isn't happening, but Y is. Lets try and make Y as non-sucky as possible". In my mind, that's far more productive, and I encourage you all to
543:
of satisfying the community and stop bothering to even try to engage with it, or they stop trying to develop beneficial features at all." He
1195:
to give us another chance on this front, but I hope you will, because if you talk to the aforementioned editors you'll find out that we
90:
626:
I don't think anyone in the developer community is dismissive or hostile towards editors, either in general or as a community. There
1022:
Yes, a lot of us were pretty shocked at the technicians' "fuck you" attitude to our clear consensus. The issue remains unresolved.
443:
If it's to be a blame-game, can you say how they've marginalised themselves? I'm not aware of marginalising myself, for example.
266:
I believe this attempt to categorise only the readers as users, in disregard of the 90K editors, is part of the problem. Editors
1327:
1302:
1293:
thread of the conversation, simply because I'm not sure if it's going anywhere that hasn't already been discussed ad infinitum.
1284:
1270:
1233:
1219:
1208:
1168:
1149:
1138:
1119:
1101:
1092:
1065:
1053:
1035:
1016:
1001:
966:
912:
833:
818:
735:
710:
672:
600:
571:
519:
473:
456:
438:
429:
374:
365:
351:
337:
317:
291:
247:
212:
197:
177:
162:
142:
126:
56:
497:"business" requirements has ever been implemented. One really good example of this is date formattingāwhich was something that
308:
community, but please leave the reader community out of it. Since "users" is a superset, please reduce to simply "editors". --
695:
774:
615:
What I was quoted on (and while I don't mind the quote and stand by it, it would have been nice to be informed that I had
576:
We all just flew into Berlin for the hackathon. We're not ignoring the discussion, we're just recovering from our flights.
1177:
And if I had to give a reason why you should trust us to listen on this, I'd say, well, because we're listening. Talk to
850:
Yes, unfocused bloat is what you'll get from the community if you don't go about it in a smart, structured way. There
720:
416:
achieved) will be hard to define, however I'm convinced that a better result will eventuate for WP when it has been.
1083:
933:
You speak a lot of sense here, Tony; I disagree on a few principles, but agree on all the substantive conclusions.
1190:
all this project-centric feedback - it's why you have the opportunity to play with the software and criticise it
724:
478:
I don't accept your examples as demonstrating the point you are trying to make (however if you want to provide
405:
147:
The definition of "user" needs a little work, says User:Tony1. You might have two sets of users on the table.
941:
tangential issue, because blue-sky projects can succeed or fail with the community just like little changes:
757:
829:
805:
Similarly just read the immense frustrations at the Maths project about the delays in implementing MathJAX.
1298:
1280:
1229:
1204:
1061:
704:
182:
I don't see confusion, and "user" is the term that Jarry, the regular journalist for this report, chose.
1324:
1114:
992:, where we can then code review and deploy it to the production systems. We'd love to have your help! --
961:
667:
401:
761:
1049:
397:
361:
347:
313:
243:
208:
173:
138:
946:
683:
997:
596:
581:
469:
942:
1224:
Thanks!Ā :). I do my best. Hopefully we can rebuild; I'm under no illusions that it'll take time.
1214:
1163:
1011:
825:
732:
516:
426:
1178:
1294:
1276:
1225:
1200:
1057:
773:
try to use the WP's link to Streetmap.co.uk, or the 19th century old-maps.co.uk site for e.g.
700:
299:(or should have) equal voices - which is what I am stating is wrong. 499.9 million users do
1321:
1144:
1108:
1087:
955:
814:
661:
493:
I also don't believe that an appropriate methodology for the community contributing towards
1044:
989:
984:
community, like MediaWiki is. If you'd like to help with these problems, please join us in
657:
412:
to development will also assist those who are in a position to prioritise development work.
1317:
1265:
1186:
1133:
1030:
907:
566:
451:
357:
343:
331:
309:
285:
239:
230:
204:
191:
169:
156:
134:
120:
89:, ... There are other initiatives where weāre partnering with the editing community the
95:
1098:
993:
592:
465:
435:
371:
53:
945:(PDF book renderer) is an example of a project that utterly bombed with enwiki, while
687:
729:
513:
423:
716:
691:
1082:@Happy-melon: I simply don't understand why we don't have at least something like
988:. In Labs you can fix the issue, demo it, and add the necessary support into our
893:... improvements to team culture and team collaboration, are equally important."
867:
1182:
886:
bottleneck, we will always fall behind, no matter how responsive we aim to be."
810:
797:, and repeatedly raised since. Yet in all that time... nothing. And meanwhile
778:
794:
85:
in January that "The Foundation will lead on technical initiatives such as the
1258:
1126:
1023:
900:
559:
444:
324:
278:
223:
184:
149:
113:
1213:
You, in particular, I'll give credit for trying awfully hard. Here's hoping!
238:
Then perhaps Jarry needs to correct his captions, as they are misleading. --
503:
587:
With Agile, the community can easily be part of the process by writing
78:
The current fluffy model seems to emphasise little things. Sue Gardner
802:
what new colour we can turn the most recent changes on my watchlist.
790:
1143:@Tony: I would help and try to translate Raymond's German msgsĀ ;)
985:
66:
Userādeveloper divide is the result of a confused relationship
789:
and what needs to be done to fix it, even including links to
756:-- experience. For example, if you look at the archives of
1252:
Could we return to exactly why Erik Mƶller thought it was
770:
698:projects, all of which have public specifications.
1086:where always new stuff is posted, nearly all day!
848:billion different opinions and doesn't understand.
1056:so we can make this as good a tool as it can be.
723:page (that was started 60 weeks ago) and even a
168:fix the headline to be more accurate and NPOV.--
1289:Note that I'm going to sort of disengage from
18:Knowledge (XXG) talk:Knowledge (XXG) Signpost
8:
866:A few major points in the tech department's
404:which then leads to the (very important)
950:contributions of individual developers.
558:editors' fault, not the technicians'.
7:
841:Let's get to the meat of the matter.
1084:de:Knowledge (XXG):Projektneuheiten
990:configuration management repository
883:We can't afford review bottlenecks.
75:dissociated from editorial needs.
891:We must reduce our technical debt.
24:
781:. This has been known about for
27:
686:for most software and Meta for
1:
876:We will connect with the user
775:White_Tower_(Tower_of_London)
758:Commons:Graphics village pump
649:when a decision has been made
623:a fairly unappealing portent.
719:project; that project has a
1275:You'd have to ask ErikĀ :).
728:requirements:". Thank you.
1343:
402:requirements specification
217:I wasn't "directed" to do
133:to the original wording.--
1199:been trying our hardest.
779:in the middle of the moat
633:which it demanded be done
537:blame the editors, not us
1328:22:10, 1 June 2012 (UTC)
1303:12:35, 7 June 2012 (UTC)
1285:10:09, 7 June 2012 (UTC)
1271:03:00, 7 June 2012 (UTC)
1234:22:28, 6 June 2012 (UTC)
1220:21:14, 6 June 2012 (UTC)
1209:20:52, 6 June 2012 (UTC)
1169:01:22, 6 June 2012 (UTC)
1150:10:54, 6 June 2012 (UTC)
1139:10:16, 6 June 2012 (UTC)
1120:09:13, 6 June 2012 (UTC)
1102:19:04, 5 June 2012 (UTC)
1093:18:07, 5 June 2012 (UTC)
1066:17:22, 5 June 2012 (UTC)
1036:05:31, 5 June 2012 (UTC)
1017:04:51, 5 June 2012 (UTC)
1002:09:21, 1 June 2012 (UTC)
967:09:44, 1 June 2012 (UTC)
913:03:10, 1 June 2012 (UTC)
834:19:10, 31 May 2012 (UTC)
819:18:36, 31 May 2012 (UTC)
791:drop-in replacement code
736:00:15, 1 June 2012 (UTC)
715:Since you mentioned the
711:18:02, 31 May 2012 (UTC)
673:11:52, 31 May 2012 (UTC)
601:10:27, 31 May 2012 (UTC)
580:It's a great example of
572:03:53, 31 May 2012 (UTC)
520:02:37, 31 May 2012 (UTC)
474:14:07, 30 May 2012 (UTC)
457:13:29, 30 May 2012 (UTC)
439:11:12, 30 May 2012 (UTC)
430:22:06, 29 May 2012 (UTC)
406:functional specification
375:09:51, 29 May 2012 (UTC)
366:06:28, 29 May 2012 (UTC)
352:06:26, 29 May 2012 (UTC)
338:06:24, 29 May 2012 (UTC)
318:06:22, 29 May 2012 (UTC)
292:06:15, 29 May 2012 (UTC)
248:06:05, 29 May 2012 (UTC)
213:05:54, 29 May 2012 (UTC)
198:05:50, 29 May 2012 (UTC)
178:05:45, 29 May 2012 (UTC)
163:05:42, 29 May 2012 (UTC)
143:05:31, 29 May 2012 (UTC)
127:03:33, 29 May 2012 (UTC)
57:14:21, 28 May 2012 (UTC)
793:that would fix it, all
750:Arbitrary section break
785:, including precisely
396:At the highest level,
1050:try out the prototype
1054:any feedback you can
795:filed four years ago
771:recently pointed out
701:Steven Walling (WMF)
398:software development
783:at least four years
777:and you get dumped
582:design by committee
388:that affect readers
400:is initiated by a
92:feedback dashboard
46:Discuss this story
1218:
1167:
1015:
696:editor engagement
40:Technology report
1334:
1268:
1263:
1217:
1166:
1147:
1136:
1131:
1090:
1033:
1028:
1014:
910:
905:
709:
707:
653:to the sysadmins
569:
564:
454:
449:
393:
336:
334:
329:
290:
288:
283:
235:
233:
228:
196:
194:
189:
161:
159:
154:
125:
123:
118:
38:
31:
1342:
1341:
1337:
1336:
1335:
1333:
1332:
1331:
1315:
1266:
1259:
1145:
1134:
1127:
1088:
1031:
1024:
908:
901:
752:
721:Software design
705:
699:
567:
560:
506:documentation).
452:
445:
391:
332:
325:
323:
286:
279:
277:
231:
224:
222:
192:
185:
183:
157:
150:
148:
121:
114:
112:
97:new page triage
68:
49:
48:
43:
36:
22:
21:
20:
12:
11:
5:
1340:
1338:
1314:
1311:
1310:
1309:
1308:
1307:
1306:
1305:
1249:
1248:
1247:
1246:
1245:
1244:
1243:
1242:
1241:
1240:
1239:
1238:
1237:
1236:
1175:
1160:
1159:
1158:
1157:
1156:
1155:
1154:
1153:
1152:
1073:
1072:
1071:
1070:
1069:
1068:
1045:New Pages Feed
1007:
1006:
1005:
1004:
978:
977:
976:
975:
974:
973:
972:
971:
970:
969:
951:
938:
934:
922:
921:
920:
919:
918:
917:
916:
915:
896:
895:
894:
887:
879:
806:
803:
766:
765:
751:
748:
747:
746:
745:
744:
743:
742:
741:
740:
739:
738:
644:
636:
624:
608:
607:
606:
605:
604:
603:
585:
577:
555:
552:
548:
540:
527:
526:
525:
524:
523:
522:
511:
507:
491:
488:
461:
460:
459:
421:
417:
413:
394:
383:
382:
381:
380:
379:
378:
377:
354:
295:
294:
263:
262:
261:
260:
259:
258:
257:
256:
255:
254:
253:
252:
251:
250:
67:
64:
62:
60:
59:
47:
44:
33:
32:
26:
25:
23:
15:
14:
13:
10:
9:
6:
4:
3:
2:
1339:
1330:
1329:
1326:
1323:
1319:
1312:
1304:
1300:
1296:
1292:
1288:
1287:
1286:
1282:
1278:
1274:
1273:
1272:
1269:
1264:
1262:
1255:
1251:
1250:
1235:
1231:
1227:
1223:
1222:
1221:
1216:
1215:Seraphimblade
1212:
1211:
1210:
1206:
1202:
1198:
1193:
1188:
1184:
1180:
1176:
1172:
1171:
1170:
1165:
1164:Seraphimblade
1161:
1151:
1148:
1142:
1141:
1140:
1137:
1132:
1130:
1123:
1122:
1121:
1118:
1117:
1112:
1111:
1105:
1104:
1103:
1100:
1096:
1095:
1094:
1091:
1085:
1081:
1080:
1079:
1078:
1077:
1076:
1075:
1074:
1067:
1063:
1059:
1055:
1051:
1046:
1041:
1040:
1039:
1038:
1037:
1034:
1029:
1027:
1021:
1020:
1019:
1018:
1013:
1012:Seraphimblade
1003:
999:
995:
991:
987:
982:
981:
980:
979:
968:
965:
964:
959:
958:
952:
948:
944:
939:
935:
932:
931:
930:
929:
928:
927:
926:
925:
924:
923:
914:
911:
906:
904:
897:
892:
888:
884:
880:
877:
873:
872:
871:
870:are relevant:
869:
868:2012ā13 goals
864:
860:
856:
853:
846:
843:I'm afraid I
842:
839:
838:
837:
836:
835:
831:
827:
826:Rusty Cashman
822:
821:
820:
816:
812:
807:
804:
800:
796:
792:
788:
787:why it occurs
784:
780:
776:
772:
768:
767:
763:
759:
754:
753:
749:
737:
734:
731:
726:
722:
718:
717:visual editor
714:
713:
712:
708:
702:
697:
693:
692:visual editor
689:
685:
684:mediawiki.org
680:
676:
675:
674:
671:
670:
665:
664:
659:
654:
650:
645:
642:
637:
634:
629:
625:
622:
618:
614:
613:
612:
611:
610:
609:
602:
598:
594:
590:
586:
583:
578:
575:
574:
573:
570:
565:
563:
556:
553:
549:
546:
541:
538:
534:
531:
530:
529:
528:
521:
518:
515:
512:
508:
505:
500:
496:
492:
489:
486:
481:
477:
476:
475:
471:
467:
462:
458:
455:
450:
448:
442:
441:
440:
437:
433:
432:
431:
428:
425:
422:
418:
414:
411:
407:
403:
399:
395:
389:
384:
376:
373:
369:
368:
367:
363:
359:
355:
353:
349:
345:
341:
340:
339:
335:
330:
328:
321:
320:
319:
315:
311:
307:
302:
297:
296:
293:
289:
284:
282:
274:
269:
265:
264:
249:
245:
241:
237:
236:
234:
229:
227:
220:
216:
215:
214:
210:
206:
201:
200:
199:
195:
190:
188:
181:
180:
179:
175:
171:
166:
165:
164:
160:
155:
153:
146:
145:
144:
140:
136:
131:
130:
129:
128:
124:
119:
117:
109:
107:
101:
99:
98:
94:
93:
88:
87:visual editor
84:
83:
76:
72:
65:
63:
58:
55:
51:
50:
45:
42:
41:
30:
19:
1316:
1295:Okeyes (WMF)
1290:
1277:Okeyes (WMF)
1260:
1253:
1226:Okeyes (WMF)
1201:Okeyes (WMF)
1196:
1191:
1128:
1115:
1109:
1058:Okeyes (WMF)
1052:and give us
1025:
1008:
962:
956:
902:
890:
882:
875:
865:
861:
857:
851:
849:
844:
840:
799:every single
798:
678:
668:
662:
652:
648:
640:
632:
627:
620:
616:
589:user stories
588:
561:
544:
536:
532:
498:
494:
479:
446:
409:
387:
326:
305:
300:
280:
272:
267:
225:
218:
186:
151:
115:
110:
105:
102:
96:
91:
86:
81:
77:
73:
69:
61:
39:
1322:Jasper Deng
1320:, admins!--
947:AbuseFilter
762:WP:SVG Help
510:life-cycle.
1187:Tom Morris
943:Collection
855:deadlines.
358:Jorm (WMF)
344:Jorm (WMF)
310:Jorm (WMF)
240:Jorm (WMF)
205:Jorm (WMF)
170:Jorm (WMF)
135:Jorm (WMF)
1099:Jarry1250
994:Ryan lane
593:Ryan lane
466:Ryan lane
436:Jarry1250
372:Jarry1250
80:told the
54:Jarry1250
1318:Heads up
730:GFHandel
688:research
533:Comment:
514:GFHandel
504:Use case
480:specific
424:GFHandel
219:anything
203:Jarry.--
108:page).
106:Signpost
82:Signpost
1267:(talk)
1135:(talk)
1032:(talk)
909:(talk)
725:Sandbox
568:(talk)
453:(talk)
37:Back to
1325:(talk)
1183:Bensin
1146:mabdul
1089:mabdul
811:Jheald
679:anyone
499:seemed
495:proper
420:users.
333:(talk)
306:editor
287:(talk)
232:(talk)
193:(talk)
158:(talk)
122:(talk)
1116:melon
1110:Happy
963:melon
957:Happy
845:don't
669:melon
663:Happy
410:prior
16:<
1313:IPv6
1299:talk
1291:this
1281:talk
1261:Tony
1230:talk
1205:talk
1197:have
1192:here
1179:Utah
1129:Tony
1062:talk
1026:Tony
998:talk
986:Labs
903:Tony
830:talk
815:talk
706:talk
694:and
641:that
617:been
597:talk
562:Tony
551:him.
470:talk
447:Tony
362:talk
348:talk
327:Tony
314:talk
281:Tony
244:talk
226:Tony
209:talk
187:Tony
174:talk
152:Tony
139:talk
116:Tony
1254:his
1185:or
1181:or
852:are
760:or
682:on
677:If
658:BAG
485:RfC
301:not
273:not
268:are
1301:)
1283:)
1232:)
1207:)
1064:)
1000:)
878:"
832:)
817:)
703:ā¢
628:is
621:is
599:)
545:is
487:).
472:)
390:.
364:)
350:)
316:)
246:)
211:)
176:)
141:)
35:ā
1297:(
1279:(
1228:(
1203:(
1113:ā
1060:(
996:(
960:ā
889:"
881:"
874:"
828:(
813:(
733:ā¬
666:ā
595:(
539::
517:ā¬
468:(
427:ā¬
360:(
346:(
312:(
242:(
207:(
172:(
137:(
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.
