835:
might happen to know a bit about software programming - after all, our main job is supposed to be building an encyclopedia and controlling its content for quality, and making sure that the editors behave themselves. That's why I always play ignorant and give the impression that i haven't a clue. 15 hours a day initiating and managing these projects on behalf of our en.Wiki community is already enough. It's 9am now, I've worked all night on this and I'm now out of town for the rest of the day for a hospital appointment.
402:. And due to the fact that there is nobody patrolling pages at the moment excepta handfull of people who are getting it very wrong, we now have a complete team of engineers at the WMF working to improve the tools and a user right will be required. Nothing here will affect you personally if you ave established yourself already as a regular page patroller. And if you haven't it will take you 30 seconds to apply for it. Did you participate in the previous RfC?
1087:
accepted, for example, if content was added after it was tagged A3. This looks like an exploitable loophole, unless the admin reviewing the A3 is expected to also complete an NPP of the extended article (which adds to their workload). It could be better to break the link, so that both Page
Curation and Twinkle tools leave a CSDed article unpatrolled?
303:
which case they could not "patrol". The prior RfC pretty much said this should be its own group, if someone like you (who is a member of
Extended confirmed users, Page movers, Mass message senders and Pending changes reviewers, Autoconfirmed users) wants to patrol after this change you would also need to be in the patrol group. —
1060:
I understand that. But my question is one of consequences for any editor who is not an authorised patrollers. I would be comfortable that their functional capabilities would be unaffected if
Twinkle has existing inbuilt resilience to cope with the highlighted 2nd step in my example being incompatible
908:
In the discussions on this and the main page, I am seeing it said that only tiny numbers of people are currently patrolling new pages. Aside from this proposal being more likely to result in a diminution than an increase in that number, the assertion doesn't seem to match what I am seeing. Yes, there
834:
you'll see the current state of affairs and why I already have a team of WMF devs working for us on this. I have made it clear to them that we as a community do not think it appropriate to rely on, or even expect, the community volunteers to write critical core software just because we
542:
Yes, as I mention in the discussion there, there is a little bit of contradiction at that section. For example, if a user meets the grandfathered right to patrol, but it is in the autoconfirmed or reviewer group, according to the technical changes, the patrol right will be removed. And another one is
357:
I think we are 100% in agreement for "what" is trying to be done - and these terms do actually mean different things from an implementation point of view - not from a "practical" point of view. Unless I'm grossly missing something here I can't see any reason why we can't use the accurate terminology.
567:
with the technical change alone, the ability to patrol pages will be removed from someone in your groups - the proposal is that if you qualify a process will be enable to add you to the patrol group - if you don't "qualify" for automatic (which does not look like it will be automatic by the software
325:
Just to clarify, being a member of the new usergroup is necessary to perform the following (technically separate) actions: patrol pages via clicking "Mark this page as patrolled" on the right bottom corner, and use the Page
Curation tool to mark pages reviewed and apply deletion tags, is that right?
1101:
You need to decide whether you want the current situation where all and sundry are allowed to patrol new pages without any clue, letting the paid spammers in and biting the good faith editors who are victims of the
Foundation's refusal to provide them with a start page. What we are proposing here
1086:
On a related topic (while not wanting to detract from my question), thinking about the interaction of the CSD tools and your plans to make wider indexing dependent on patrolled status: Should the tools be adjusted to cease to flag "patrolled" when tagging an article for CSD? The CSD is not always
302:
permission is only included in the groups:autoconfirmed, confirmed, pending changes reviewers, and administrators. It is important to note that you can be a member of multiple groups at a time. It is technically possible to be a template editor today, and not be confirmed or autoconfirmed - in
138:
We want this project to succeed. We have escalated the issue to the level of CEO of the WMF, let's not now do anything that's going to become another toilet-roll long RfC for something clear and simple and more bulling the proposer. I don't own the project, but as the only one who is constantly
1044:
Access to
Twinkle is not affected by this new user right. Pages can be tagged but they will remain unpatrolled until patrolled through Page Curation by an authorised patroller. This provides a double (or even triple) control which should help reject the rampant incorrect tagging - or letting
1269:
If it had died down to no comments I wouldn't have a big problem. Given that there's still discussion on going I'm not so sure. Also, running the RfC for only half the advertised time might mean that others who were planning to comment later on in the process aren't able to do so.
790:
Thanks, I understand the outlook of the clause, no worries. Folks will surely find a way to make the transition as smooth as possible if the RfC passes. I'm sure as a community we'll be acting on the spirit of the grandfathering clause on the RfC in any case, whether automated or
1026:
right? Will the
Twinkle CSD function fall over at the second step? Will a re-engineering change to Twinkle need to be initiated to introduce conditional logic interrogating the user right so that it gracefully moves on to complete steps 3-5 but leaves the article unpatrolled?
680:
That is irrelevant, but the way other people take initiative here, I'll probably end up doing it myself manually. That said, it can easily be done by a script and I have someone on hand who can do it. Let's not please clog the issue up with minor technicalities at this stage.
913:
with pages appearing then being quickly picked off and (b) a range of users involved in the consequent CSDs (for example, when the originator removes the tags). Are there solid figures on the actual number of editors patrolling? (And to be clear, I am meaning the broader
1061:
with the editor's rights. But if there is a risk that
Twinkle will be unable to proceed in that circumstance and in particular would not inform the article creator, then that becomes an unplanned bad outcome consequent on the introduction of the new right.
31:
Objective criteria are important, maybe even totally necessary, but I think the core criteria should based on the performance objectives and not raw edits/days experience. This isn't a generalist permission like extended confirmed, but a specialist role.
171:
Quite so. I don't feel it, I know it. People will try to re-debate the whole thing anyway - they always do. Getting consensus for anything obvious on
Knowledge through our RfC system is a nightmare. And I thought you were supposed to be on vacation ;)
272:
Does removing the patrol permission confined to the group you've mentioned? What about other user groups? For example, Template editors and Mass message senders are no way connected to the reviewing experience. Please ping me while you reply. Regards,
1120:
The twinkle devs should review they have fall-forward error handling in the event a step fails, alternately skip steps that are impossible with the existing access - this can be programmed now without impacting anything. —
883:
I don't intend including it. It was included in the precursor RfC and I see no need to drag everything through the mill again. Knowledge editors will just jump at he opportunity to re-debate the whole thing - they
1213:
If consensus doesn't substantially change, per the "This RfC will run for 30 days or until a clear consensus is obvious", I'll be glad to close on 24 Oct 2016 (three weeks after opening the RfC). Any objections,
1144:, indicating an existing conditionality. And as it is a Tick box, those without the new right will be able to untick that preference so that Twinkle will not even evaluate the Patrol status, which seems ok.
937:
While we're looking for numbers, an actual number of editors that would be grandfathered in would be nice too. It would help determine how many people that this RFC would actually affect immediately. --
477:
of course you can participate, but as this is an extension RfC it would be very good if you would please find out what it's all about. That's why there's a link on the very top of this RfC.
761:
My question was only to determine if this was going to require a software request to developers on closing - do we have a "rough" idea (in 100's or 1000's) of editors this needs to be applied to? —
743:, with the amount of actual help that comes from other members of the community except for nit picking, I'll proably end up doing it my self manually any way, I usually do. But there
157:
No one wants their time wasted, but I'm having trouble understanding how your response matches up with the proposal. You feel that the above proposal is more likely to rathole the RfC somehow?
582:
also to be clear, you do not currently have patrol access by way of the groups you mentioned, you have it because you are in the autoconfirmed group, which is listed. —
1329:
I've actually gone ahead and closed the RfC as it's now the promised 24 October and there is an "obvious", "clear consensus". Please feel free to join if you'd like.
319:
I see we're splitting hairs over vocabulary again. You appear to have forgotten the very long (and time consuming) discussion you drew out of me on my talk page.
59:. Editors receiving the patroller right should have an editing history that demonstrates the ability and demeanor suitable for new page patrolling, particularly:
871:
is a fairly good, recent, sample of some criteria for granting - and also criteria for removal -- this may be good to model part on that are not yet included. —
431:
I don't see what this has to do with holders of user rights who are not in any way connected in new article reviewing. Did you participate in the previous RfC?
747:
ways of semi-automating it. But don't expect me to writ e the script and show you how it's going to be done; unless of course you're volunteering...
668:
The proposal has a granting line to be done "automatically" are we expecting this to be done by mediawiki software, or assisted via reports and admins? —
461:
282:
568:
but by the implementers actually click buttons) you would have to request the group if you wanted it. I'll see if this can be cleaned up a bit. —
452:
Got the point, thank you. No, I did not participate. Does that mean I should not participate now? Actually I was unaware of the RfC then. Regards,
196:
This should clearly document all the changes being made at once (not up for debate - but to have a solid documentation for the phab request)
246:
This mentions a new user "right" I think it should be a new user "permission group" - the group gets rights, users get groups. The "right"
119:
I'm also not how important it is to spell out the behavioral/3RR block exclusion in the proposal (or the other "Guidelines for granting"
524:
section? If there is something technically wrong - can you elaborate? If it just needs copyedits, style changes, etc - go for it :D —
811:
729:
457:
344:
278:
1298:: I am now prepared to close this as consensus to implement the proposed standards. Would you like to co-close? (I'm OK either way.)
830:, there are probably no more that about ten or 20 users who fall into the grandfathering parameters. If you've been following
231:
I don't think it's really necessary to add to crats (practically we're not going to be getting any non-admin 'crats) or stewards. —
1355:
1324:
1289:
1264:
1244:
1207:
1170:
1153:
1127:
1111:
1096:
1070:
1054:
1036:
972:
958:
947:
931:
897:
877:
855:
844:
816:
782:
767:
756:
734:
690:
674:
655:
640:
612:
588:
574:
559:
530:
506:
487:
465:
440:
411:
379:
364:
349:
309:
286:
256:
237:
223:
181:
166:
148:
132:
1045:
disallowed pages through into the encyclopedia. Only when correctly patrolled will they be able to be indexed by Google.--
1281:
700:
696:
370:
17:
1252:
This RfC will run for 30 days or until a clear consensus is obvious, and will be closed by any uninvolved established user.
632:
Does the (patrol) permission grants to every user originally? Since there is no specification at NPP, I supposed it would.
968:
943:
472:
453:
428:
293:
274:
500:
I added the technical summary, collapsed to the main page - if anything is factually inaccurate - please discuss here. —
1203:
123:
in the proposal, for that matter). They seem like things that the admin reviewing WP:PERM could evaluate case-by-case.
112:
submissions, an entry threshold of 90 days of active account use and 500 nontrivial edits to mainspace is suggested.
1351:
1320:
1240:
964:
939:
543:
that new user can patrol new pages, since there is no mention in the technical changes that it will be removed
952:
Did we ever get anywhere on this? As they have to be done "manually" is a list being formulated somewhere? —
963:
The RFC has been closed, and there is still no visible list of editors that are eligible for threshold 2. --
646:
776:
autopromotion schemes in the software have been very buggy (for example the autoreview group on trwiki). —
545:(Small disclaimer: I didn't know that if new user can patrol new pages since there is no mention in WP:NPP)
209:
Remove the patrol permission from the following groups: autoconfirmed; confirmed; pending changes reviewers
804:
722:
337:
1285:
868:
849:
Thanks, we would not really have a need for this to be done by the software for such a low number. —
1277:
633:
605:
579:
564:
552:
515:
206:
Localize the name of the patrollers group to "New page reviewers" (done locally in mediawiki space)
87:
707:
logs for each user. My hunch is that it's infeasible for the software to determine the number of
704:
638:
610:
557:
1022:
What is the consequence in the post-RfD scenario where the
Twinkle user does not have this new
991:
However, when one uses Twinkle to mark an article for speedy-deletion, the message sequence is:
1260:
1255:. I wouldn't have thought that a vote on the validity of that statement would be necessary. --
1133:
1107:
1050:
893:
840:
794:
752:
740:
712:
686:
483:
436:
407:
399:
327:
177:
144:
83:
831:
162:
128:
373:
and my points above match points 1,2,3 that we seemed to be in agreement with back then. —
1149:
1092:
1066:
1032:
927:
1345:
1314:
1295:
1272:
1234:
1215:
1195:
1185:
94:
56:
1165:
1122:
953:
872:
850:
827:
777:
762:
669:
650:
595:
583:
569:
537:
525:
501:
374:
359:
316:
304:
267:
251:
232:
218:
109:
101:
79:
72:
68:
1256:
1103:
1081:
1046:
889:
836:
748:
682:
479:
447:
432:
403:
354:
322:
214:
173:
140:
1194:
Does this seem like clear consensus is obvious? It's an 89% leaning support, and
1199:
158:
124:
1161:
1145:
1088:
1062:
1041:
1028:
923:
695:
I'm assuming this can be determined manually by the the sum of entries in the
27:
Suggestion: central basis of criteria should be qualitative, not quantitative
1339:
1331:
1308:
1300:
1228:
1220:
1189:
987:
Following from the consensus on the earlier RfD, the present proposal says
547:. It just need more context for the technical changes section so someone
1012:
Notifying initial contributor (User_foo): completed (User talk:User_foo)
551:
does not misunderstood the meaning of the new patroller rights. Cheers!
909:
is a massive backlog but I also see (a) significant volatility in
1102:
might not be perfect but it's a step in the right direction.
989:"Access to Twinkle is not affected by this new user right."
358:
That it is going to happen is not up for debate anymore. —
604:" get it now. Still need a bit of re-reading afterwards.
1009:
Opening page "Blah": Retrieving page creator information
120:
298:
those groups don't have this permission today. The
139:taking the initiative I don't want my time wasted.
1249:It looks as if the proposer was quite clear with
108:Based on the analogous requirement for review of
55:Requests for the patroller right will be made at
922:which captures only the subset using one tool.)
1017:Adding entry to userspace log: Saving page...
520:You mentioned something might be wrong in the
522:Summary of under the covers technical changes
8:
869:Knowledge:Page_mover#Guidelines_for_granting
38:
983:Will this require Twinkle re-engineering?
203:Add patrol permission to patrollers group
78:An understanding of key policies such as
645:For the complete information please see
41:
1164:! Seems like this is a non-issue. —
371:Special:PermaLink/736428600#NPP_Part2
93:The ability to communicate and avoid
7:
1196:voting/attempting to reach consensus
1179:"until a clear consensus is obvious"
1138:Mark page as patrolled when tagging
1136:for something else, I notice that
24:
600:Thanks for your explanation. I "
18:Knowledge talk:New pages patrol
1000:Tagging page: completed (Blah)
1:
250:isn't actually new at all. —
1356:20:31, 24 October 2016 (UTC)
1325:21:56, 23 October 2016 (UTC)
1290:07:22, 20 October 2016 (UTC)
1265:05:57, 20 October 2016 (UTC)
1245:02:06, 20 October 2016 (UTC)
1208:15:49, 19 October 2016 (UTC)
1171:15:57, 16 October 2016 (UTC)
1154:15:29, 16 October 2016 (UTC)
1128:14:52, 15 October 2016 (UTC)
1112:11:52, 11 October 2016 (UTC)
1097:10:43, 11 October 2016 (UTC)
1071:10:11, 11 October 2016 (UTC)
1055:09:38, 11 October 2016 (UTC)
1037:07:22, 11 October 2016 (UTC)
973:23:19, 24 October 2016 (UTC)
959:23:30, 19 October 2016 (UTC)
948:01:42, 11 October 2016 (UTC)
369:And I do very much remember
932:16:09, 6 October 2016 (UTC)
898:01:11, 6 October 2016 (UTC)
878:01:07, 6 October 2016 (UTC)
856:11:56, 6 October 2016 (UTC)
845:02:59, 6 October 2016 (UTC)
817:02:13, 6 October 2016 (UTC)
783:02:16, 6 October 2016 (UTC)
768:02:06, 6 October 2016 (UTC)
757:02:02, 6 October 2016 (UTC)
735:01:56, 6 October 2016 (UTC)
691:01:15, 6 October 2016 (UTC)
675:01:02, 6 October 2016 (UTC)
656:18:32, 7 October 2016 (UTC)
641:15:24, 7 October 2016 (UTC)
613:15:24, 7 October 2016 (UTC)
589:13:06, 7 October 2016 (UTC)
575:13:01, 7 October 2016 (UTC)
560:03:51, 7 October 2016 (UTC)
531:16:31, 6 October 2016 (UTC)
507:12:23, 6 October 2016 (UTC)
488:01:51, 6 October 2016 (UTC)
466:01:41, 6 October 2016 (UTC)
441:01:39, 6 October 2016 (UTC)
412:01:49, 6 October 2016 (UTC)
398:That is absolutely correct
380:02:34, 6 October 2016 (UTC)
365:02:08, 6 October 2016 (UTC)
350:01:37, 6 October 2016 (UTC)
310:02:02, 6 October 2016 (UTC)
287:01:15, 6 October 2016 (UTC)
257:01:04, 6 October 2016 (UTC)
238:00:56, 6 October 2016 (UTC)
224:00:55, 6 October 2016 (UTC)
182:01:22, 6 October 2016 (UTC)
167:01:16, 6 October 2016 (UTC)
149:01:09, 6 October 2016 (UTC)
133:00:13, 6 October 2016 (UTC)
1377:
213:Anything I'm missing here
1198:seems to have died down.
1004:Marking page as patrolled
920:type=pagetriage-curation
864:Good sample: Page movers
473:Krishna Chaitanya Velaga
454:Krishna Chaitanya Velaga
429:Krishna Chaitanya Velaga
294:Krishna Chaitanya Velaga
275:Krishna Chaitanya Velaga
200:Create patrollers groups
647:Special:ListGroupRights
772:Mostly asking because
110:Articles for Creation
43:Alternate proposal #1
911:Special:NewPagesFeed
739:Like I said above,
711:entries in these. —
709:uncontested/reverted
100:An understanding of
95:biting the newcomers
965:AntiCompositeNumber
940:AntiCompositeNumber
192:Document everything
1140:is qualified with
1338:
1307:
1227:
1132:While looking at
1018:
1014:
996:
993:
117:
116:
67:understanding of
1368:
1336:
1305:
1254:
1225:
1193:
1168:
1125:
1085:
1016:
998:
995:
992:
956:
904:Query on numbers
875:
853:
815:
807:
792:
780:
765:
733:
725:
672:
653:
636:
608:
599:
586:
572:
555:
541:
528:
519:
504:
476:
451:
377:
362:
348:
340:
307:
301:
297:
271:
254:
249:
235:
221:
39:
1376:
1375:
1371:
1370:
1369:
1367:
1366:
1365:
1364:
1257:Kudpung กุดผึ้ง
1250:
1206:
1183:
1181:
1166:
1123:
1104:Kudpung กุดผึ้ง
1079:
1047:Kudpung กุดผึ้ง
985:
969:Leave a message
954:
944:Leave a message
906:
890:Kudpung กุดผึ้ง
873:
866:
851:
837:Kudpung กุดผึ้ง
805:
801:
789:
778:
763:
749:Kudpung กุดผึ้ง
723:
719:
683:Kudpung กุดผึ้ง
670:
666:
651:
634:
606:
593:
584:
570:
553:
535:
526:
513:
502:
480:Kudpung กุดผึ้ง
470:
445:
433:Kudpung กุดผึ้ง
404:Kudpung กุดผึ้ง
375:
360:
338:
334:
305:
299:
291:
265:
252:
247:
233:
219:
194:
174:Kudpung กุดผึ้ง
141:Kudpung กุดผึ้ง
73:speedy deletion
69:deletion policy
44:
29:
22:
21:
20:
12:
11:
5:
1374:
1372:
1363:
1362:
1361:
1360:
1359:
1358:
1327:
1267:
1202:
1180:
1177:
1176:
1175:
1174:
1173:
1157:
1156:
1118:
1117:
1116:
1115:
1114:
1074:
1073:
1020:
1019:
1013:
1010:
1007:
1001:
984:
981:
980:
979:
978:
977:
976:
975:
905:
902:
901:
900:
865:
862:
861:
860:
859:
858:
824:
823:
822:
821:
820:
819:
787:
786:
785:
693:
665:
664:Automatically?
662:
661:
660:
659:
658:
626:
625:
624:
623:
622:
621:
620:
619:
618:
617:
616:
615:
499:
498:
497:
496:
495:
494:
493:
492:
491:
490:
421:
420:
419:
418:
417:
416:
415:
414:
389:
388:
387:
386:
385:
384:
383:
382:
352:
314:
313:
312:
260:
259:
243:
242:
241:
240:
211:
210:
207:
204:
201:
193:
190:
189:
188:
187:
186:
185:
184:
152:
151:
115:
114:
106:
105:
102:categorization
98:
91:
76:
46:
45:
42:
37:
28:
25:
23:
15:
14:
13:
10:
9:
6:
4:
3:
2:
1373:
1357:
1353:
1350:
1347:
1344:
1341:
1334:
1333:
1328:
1326:
1322:
1319:
1316:
1313:
1310:
1303:
1302:
1297:
1293:
1292:
1291:
1287:
1283:
1279:
1275:
1274:
1268:
1266:
1262:
1258:
1253:
1248:
1247:
1246:
1242:
1239:
1236:
1233:
1230:
1223:
1222:
1217:
1212:
1211:
1210:
1209:
1205:
1201:
1197:
1191:
1187:
1178:
1172:
1169:
1163:
1159:
1158:
1155:
1151:
1147:
1143:
1142:(if possible)
1139:
1135:
1131:
1130:
1129:
1126:
1119:
1113:
1109:
1105:
1100:
1099:
1098:
1094:
1090:
1083:
1078:
1077:
1076:
1075:
1072:
1068:
1064:
1059:
1058:
1057:
1056:
1052:
1048:
1043:
1039:
1038:
1034:
1030:
1025:
1015:
1011:
1008:
1005:
1002:
999:
997:
994:
990:
982:
974:
970:
966:
962:
961:
960:
957:
951:
950:
949:
945:
941:
936:
935:
934:
933:
929:
925:
921:
917:
912:
903:
899:
895:
891:
887:
882:
881:
880:
879:
876:
870:
863:
857:
854:
848:
847:
846:
842:
838:
833:
829:
826:
825:
818:
813:
810:
808:
800:
799:
798:
788:
784:
781:
775:
771:
770:
769:
766:
760:
759:
758:
754:
750:
746:
742:
738:
737:
736:
731:
728:
726:
718:
717:
716:
710:
706:
702:
698:
694:
692:
688:
684:
679:
678:
677:
676:
673:
663:
657:
654:
648:
644:
643:
642:
639:
637:
631:
628:
627:
614:
611:
609:
603:
597:
592:
591:
590:
587:
581:
578:
577:
576:
573:
566:
563:
562:
561:
558:
556:
550:
546:
539:
534:
533:
532:
529:
523:
517:
512:
511:
510:
509:
508:
505:
489:
485:
481:
474:
469:
468:
467:
463:
459:
455:
449:
444:
443:
442:
438:
434:
430:
427:
426:
425:
424:
423:
422:
413:
409:
405:
401:
397:
396:
395:
394:
393:
392:
391:
390:
381:
378:
372:
368:
367:
366:
363:
356:
353:
351:
346:
343:
341:
333:
332:
331:
324:
321:
320:
318:
315:
311:
308:
295:
290:
289:
288:
284:
280:
276:
269:
264:
263:
262:
261:
258:
255:
245:
244:
239:
236:
230:
229:
228:
227:
226:
225:
222:
216:
208:
205:
202:
199:
198:
197:
191:
183:
179:
175:
170:
169:
168:
164:
160:
156:
155:
154:
153:
150:
146:
142:
137:
136:
135:
134:
130:
126:
122:
113:
111:
103:
99:
96:
92:
89:
85:
81:
77:
74:
70:
66:
62:
61:
60:
58:
53:
52:
48:
47:
40:
36:
33:
26:
19:
1348:
1342:
1330:
1317:
1311:
1299:
1271:
1251:
1237:
1231:
1219:
1182:
1141:
1137:
1040:
1023:
1021:
1003:
988:
986:
919:
918:rather than
915:
910:
907:
885:
867:
803:
796:
795:
773:
744:
741:Andy M. Wang
721:
714:
713:
708:
701:deletion tag
667:
629:
601:
548:
544:
521:
400:Andy M. Wang
336:
329:
328:
212:
195:
118:
107:
88:WP:VANDALISM
64:
54:
50:
49:
34:
30:
916:type=patrol
35:How about:
1134:WP:TW/PREF
326:Thanks, —
84:WP:COPYVIO
1296:Callanecc
1273:Callanecc
1216:Callanecc
1186:Callanecc
1024:Patroller
832:WP:NPPAFC
549:(like me)
121:currently
1282:contribs
1204:Contribs
1167:xaosflux
1124:xaosflux
955:xaosflux
874:xaosflux
852:xaosflux
828:Xaosflux
779:xaosflux
764:xaosflux
697:curation
671:xaosflux
652:xaosflux
635:NgYShung
630:Question
607:NgYShung
596:Xaosflux
585:xaosflux
580:NgYShung
571:xaosflux
565:NgYShung
554:NgYShung
538:Xaosflux
527:xaosflux
516:NgYShung
503:xaosflux
376:xaosflux
361:xaosflux
317:Xaosflux
306:xaosflux
300:(patrol)
268:Xaosflux
253:xaosflux
248:(patrol)
234:xaosflux
220:xaosflux
65:thorough
51:Proposal
1200:Dat Guy
1160:Thanks
1082:Kudpung
797:Andy W.
774:complex
715:Andy W.
602:sort of
478:Thanks.
448:Kudpung
355:Kudpung
330:Andy W.
323:Kudpung
215:Kudpung
57:WP:PERM
1006:: done
886:always
705:patrol
703:, and
159:VQuakr
125:VQuakr
86:, and
80:WP:BLP
1332:Kevin
1301:Kevin
1221:Kevin
1162:AllyD
1146:AllyD
1089:AllyD
1063:AllyD
1042:AllyD
1029:AllyD
924:AllyD
888:do.
97:, and
16:<
1340:L235
1309:L235
1294:Hey
1286:logs
1278:talk
1261:talk
1229:L235
1190:L235
1188:and
1150:talk
1108:talk
1093:talk
1067:talk
1051:talk
1033:talk
928:talk
894:talk
841:talk
806:talk
791:not.
753:talk
724:talk
687:talk
649:. —
484:talk
462:mail
458:talk
437:talk
408:talk
339:talk
283:mail
279:talk
217:? —
178:talk
163:talk
145:talk
129:talk
71:and
1337:aka
1306:aka
1226:aka
812:ctb
745:are
730:ctb
345:ctb
1354:)
1323:)
1288:)
1284:•
1280:•
1263:)
1243:)
1218:?
1152:)
1110:)
1095:)
1069:)
1053:)
1035:)
971:)
946:)
930:)
896:)
843:)
793:—
755:)
699:,
689:)
681:--
486:)
464:)
460:•
439:)
410:)
285:)
281:•
180:)
165:)
147:)
131:)
82:,
63:A
1352:c
1349:·
1346:t
1343:·
1335:(
1321:c
1318:·
1315:t
1312:·
1304:(
1276:(
1259:(
1241:c
1238:·
1235:t
1232:·
1224:(
1192::
1184:@
1148:(
1106:(
1091:(
1084::
1080:@
1065:(
1049:(
1031:(
967:(
942:(
926:(
892:(
839:(
814:)
809:·
802:(
751:(
732:)
727:·
720:(
685:(
598::
594:@
540::
536:@
518::
514:@
482:(
475::
471:@
456:(
450::
446:@
435:(
406:(
347:)
342:·
335:(
296::
292:@
277:(
270::
266:@
176:(
161:(
143:(
127:(
104:.
90:,
75:,
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.