GuildWiki talk:Publish your build

Intriguing, and a seemingly nice compromise.--Nog64Talk 22:48, 4 April 2007 (CDT)
 * Well yeah, if we're ever going to get any of these build policies off the ground we're going to have to reach a compromise. Thanks for taking the time and writing this up Vazze, a friend and I were doing something very similiar to this as a policy suggestion. This looks generally good. Needs to be expanded a bit more, but a good start. Isis In De Nile 23:58, 4 April 2007 (CDT)

Navigation
Here is something; John Doe wants to look over all Original Builds that have to do with Necromancers. However, this would require John Doe to go through journal after journal (which are all listed on the library) to look at each one individually. There should be some framework in which John Doe, if he chooses, to have access to all Necromancer builds that exist within all the journals. Just a small point raised here. Isis In De Nile 00:19, 5 April 2007 (CDT)
 * A build type [GvG,HA..Farming...Running]  X    profession [Mo, N...Team]) table that contains links to build directories in different libraries will probably help. As long as there are less than say 3-5 links for a given combination, this is ok. The idea is to decentralize the builds section to ease the load on the management side, creating pages that combine libraries goes the opposite direction.--Vazze 13:14, 5 April 2007 (CDT)

And how is this different from the system that is already in place? We are going to experience the same problems. =| Caramel Ni 13:17, 5 April 2007 (CDT)
 * We? No, perhaps the editors, but since the library is in their userspace, they can solve their problems very efficiently, or if they don't, you just stop visiting that page, and use another library. --Vazze 13:50, 5 April 2007 (CDT)
 * So this is a variation of GW:NOB where no build section exists? In NOB popular, well known, succesfull builds are allowed in the build name space and everything else is allowed in the user name space, hoping that some nice rules will be created by users for their own user name space to be used for original builds. --[[Image:Gem-icon-sm.png]] (gem / talk) 14:02, 5 April 2007 (CDT)


 * Ahh, thanks for the help. I thought you were talking about having just ONE library. But also, don't you think it will use alot of server space with each person having their OWN library, holding builds that hundreds of other people already have listed? or is the suggestion that it just links? Caramel Ni 14:21, 5 April 2007 (CDT)


 * I think that there wont be too much same builds in the user name spaces as all popular builds are documented in the build name space. Remember that even now with the old policy people have their own builds in their name space. This system would just allow users to categorise all builds and build ideas in their user name space to easy-to-search categories.
 * The reason why I like the idea of allowing users to post builds in any user name space (if the name space owner has rules for posting builds in his/her name space) is that users may select freely which rules they want to follow as different name space owners will surely have different rules for veting/deletion etc. --[[Image:Gem-icon-sm.png]] (gem / talk) 14:28, 5 April 2007 (CDT)
 * I did not specify (edit:actually I did, correcting it) whether builds or build links should be submitted to editors. If it is build link only, and the editor trusts the author that he/she will keep updating the build but he/she will not make substantial changes, it can be good for the editor. However, some editors might want to update builds themselves or with their team. Build size (kB) may also present some problems for the editor. But I think the best thing is not to define the way builds are stored on the editor pages (it is user name space after all). --Vazze 14:59, 5 April 2007 (CDT)
 * I think it's up to the user who allows others to post in his user name space to decide what the rules are. For example someone might say that anyone can submit a build, but if the user name space owner has an opinnion on the build, his changes may not be reverted. Another one might implement a vetting system of some kind and so on. --[[Image:Gem-icon-sm.png]] (gem / talk) 15:15, 5 April 2007 (CDT)
 * I'd say this just pushes all those horrid discussions to the user space. The fact that discussions would be taking place over dozens of talk pages inside the user space will make it even harder to filter out build discussions for those who aren't interested. The only thing this appears to solve is that it'll cater to the egos of the makers of poor and mediocre builds in that they can at least create their own Workshop to post their own builds and hopefully make them less likely to violate GW:NPA. -- Ab.Er.Rant  (msg Aberrant80) 22:12, 5 April 2007 (CDT)
 * People are publishing their builds in their user name space even now, with the old system. I don't think it will be such a big problem even if we set something 'official' like categories for it. --[[Image:Gem-icon-sm.png]] (gem / talk) 07:32, 6 April 2007 (CDT)
 * I'd prefer categories to directories. -- Gordon Ecker 20:40, 7 April 2007 (CDT)

Responsibility without Authority?
So, if I decide to open up a library, we're stating here that I can set the rules for my library. How do I enforce these rules? Suppose user FUBAR creates a page in my namespace, puts a build there that, for whatever reason, violates my rules. What can I actually do about it? I don't have the authority to delete the page. I don't have the authority to ban him from posting in my area. I don't have the authority to lock the page. In short, I don't have any recourse at all except to appeal to the admins. The whole problem with the current buildspace is that it has grown to such a large monstrosity with many violations of GW:NPA and more that the admins are unable to reasonably police it. The whole reason to move it to userspace, as I see it, is to shift that burden to the owners of the userspace page and thus shift the responsiblity of enforcing the rules to said user. The problem I see, and I don't know how to resolve, is that users don't have the authority to enforce the rules they set. The obvious answer of "mark it with a template and have the admins do it" just shifts the burden back onto the admins, possibly with more of an issue than what we have now. I don't see how this really helps anything. ScionOfErixalimar 23:25, 5 April 2007 (CDT)
 * "I don't have the authority to delete the page." Every user may tag anything in their user name space for deletion and it will be deleted (I guess the user talk page is different though). This gives you full dictatorship over your name space so that no one can post stuff there just to irritate you. --[[Image:Gem-icon-sm.png]] (gem / talk) 07:34, 6 April 2007 (CDT)
 * So my only recourse is to delete, and I can't stop the person from reposting. It seems that this would lead to turf wars and require the admins to step in.  Yes, it will be obvious who wins (the owner of the namespace), but I don't see that a lot of little turf wars is going to alleviate the burden on the admins.  I may be being overly cynical, but I'm an engineer...it's my job.  ScionOfErixalimar 13:47, 6 April 2007 (CDT)
 * If someone wants to terrorise and break rules, they will do it regardless of this user name space build change. --[[Image:Gem-icon-sm.png]] (gem / talk) 16:01, 6 April 2007 (CDT)
 * Agreed...but outside of the User namespace, you get smacked down quickly by an Admin for it. The whole point, as I understand it, of User Space is that the admins don't police it the same as they do mainline namespaces...feel free to correct this impression if I'm wrong.  148.87.1.172 16:16, 6 April 2007 (CDT)
 * The question is how motivated the user is to resort to vandalism. In the previous build section, voting was able to polarize the testing group very efficiently (favored <-> unfavored). In this model, the comments will be cooperative, because only the editor (or his reviewer) decides. The editor is not likely to be the target of authors either, because they both ask a favor from each other: author wants publicity and the editor has to provide content. The worst thing that can happen is that the author gets offended because his favorite build was not accepted, (/editor was rude), so the author won't publish at that editor again. --Vazze 16:27, 6 April 2007 (CDT)
 * Admins do currently act quickly if a users user name space is attacked and I don't see this changing with the suggested build system. --[[Image:Gem-icon-sm.png]] (gem / talk) 16:47, 6 April 2007 (CDT)

Opinion Poll
Support Oppose
 * 1) Unless someone can think of a better way to put OB's on the wiki, I'm sticking with this one. The main reason for doing this is becuase it creates an air of cooperation over competition in the wiki.--Nog64Talk [[Image:Yaaaay.png|19px]] 18:49, 6 April 2007 (CDT)
 * 2) Since we are going to GW:NOB this policy seems mandatory. --Gwain 10:35, 11 April 2007 (CDT)
 * 3) Support, assuming that GW:NOB passes. It's not great, but I haven't seen any better proposals for handling original builds. Categorization can be handled in Style and formatting/Builds. -- Gordon Ecker 23:22, 12 April 2007 (CDT)
 * 4) Support, there should still be at least a somewhat convenient way to have original builds out there to be improved and critiqued, and this is about the closest one to that end. FRD 01:16, 17 April 2007 (CDT)
 * 1) I personally think this is a step in the right direction, but nothing more then that; a step. As a policy, I personally think it will simply complicate the build development to an unneeded degree, and create more work then is necessary. --[[image:GEO-logo.png]] Jioruji Derako.> 01:02, 13 April 2007 (CDT)

Ummmm
Sorry, but this looks like a half assed attempt to give the problems to others. It makes a even more unorganized mess of builds now on many userpages instead of in categorys. Theres only one page to delete sure but then theres a bunch of pages taking up space in userspace. I don't see how a angry build author couldn't just strike out any unfavored vote. The whole description is a little sketchy there, basically from what I understand there will be a bunch of separate user created policies each that could be used to the authors advantage. This is much much worse form the current voting system. Maybe I'm not understanding this but from what I can decipher from this it doesn't look like a improvement.--Sefre  00:12, 7 April 2007 (CDT)
 * Except no one votes.--Nog64Talk [[Image:Yaaaay.png|19px]] 15:50, 7 April 2007 (CDT)

Is this what it would look like?
Defiant Elements has produced a "build collaboration" a database of user builds that, as the name says encourages collaboration to make nice builds. I was wondering if this was what we were looking for.--Nog64Talk 11:25, 15 April 2007 (CDT)
 * Why a manually maintained list instead of a few categories, like 'User build stub', 'User build idea', etc? --[[Image:Gem-icon-sm.png]] (gem / talk) 06:46, 16 April 2007 (CDT)
 * If PYB will ever be a policy, Defiant will have a head start. However I am not so optimistic about the future of this policy. Those who want to keep OBs on Wiki did not give up yet and they are not willing to visit userpages for builds (/authors are not willing to submit builds for editors?).
 * Another potential problem is that everybody is copying builds like there is no tomorrow, and this system is not going to work with 100+ Workshops. I created a "Build Discussion" page example, so we know what we are talking about.


 * Workshops sorted according to Area/Profession specific and General because: small focused>>small general, protect small Workshops from large ones
 * Invited famous outsider: external quality control, only with positive input.
 * Number of Builds is displayed: size matters,
 * categories: categories on builds dump everything into one library, which is very bad (except in the case of Build Stubs/Untested, it is good to collect those)
 * Copying: there is no way to stop copying (stealing), so there will not be "copy protection", law enforcement, etc.
 * Build discussion page is edited by editors (nothing there that they can not do)


 * needed:
 * mechanism to avoid 100+ mini-libraries (in case it is a danger). This is going to be difficult, so I suggest we finish the other things before going into this one.
 * internal popularity index, what options do we have here, could admins comment on this?
 * --Vazze 14:14, 16 April 2007 (CDT)


 * Why a few categories? Why not a huge number of categories like user DoA builds, user GvG bulids and user general PvE builds, further subcategorized based on progress / testing status? -- Gordon Ecker 21:34, 16 April 2007 (CDT)


 * I didn't mean that the amount of categories should be limited, I just wanted to point out that categories are better than a manually handled list. --[[Image:Gem-icon-sm.png]] (gem / talk) 22:34, 16 April 2007 (CDT)


 * Yeah, the general message I was trying to convey was "great idea, I think we should take it a step further", but I see how it could be misinterpreted. -- Gordon Ecker 22:46, 16 April 2007 (CDT)


 * I think I misunderstood before, Workshops(Build type) categories are ok (helps with maintenance), although we can not sort workshops according to the number of build or other parameters (also a big table is prettier IMO). --71.72.50.141 01:01, 18 April 2007 (CDT)