Help talk:Wiki Conventions

From ISFDB
Revision as of 13:03, 6 January 2011 by Uzume (talk | contribs) (→‎User page)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Much of this discussion was originally posted on ISFDB:Community Portal#Help:Conventions Opinions sought and was later moved here. -DES Talk 20:02, 7 August 2009 (UTC)

Superpowers

We will need to clarify what superpowers Al and I claim in addition to our uncanny ability to install software. Ahasuerus 03:19, 5 August 2009 (UTC)

I figured leaving it vague would leave it to your good judgment, while making it clear that it was very rare that any such would be exercised. Obviously policy changes that aren't technically possible to implement in software would come under the veto, as would policies involving excessive legal risk, as Al (as the owner of the domain) would be the person most likely at risk if any risk there were. -DES Talk 14:59, 5 August 2009 (UTC)
I like your rewordings, in general. The reason I included "(or should not)" was to acknowledge that sometimes moderators are accorded a degree of deference in wiki discussions that in theory they should not get. But perhaps it is best not to mention that in such a document. -DES Talk 14:59, 5 August 2009 (UTC)

Summaries

How far do people think this is from being ready for prime time? -DES Talk 14:59, 5 August 2009 (UTC)

No complaints about what's there, but there are some additions I'd like to see. For instance, you once explained to me that changing an existing "Summary" on an edit broke stuff if I changed the bit between "/*" and "*/" so I now add stuff only after that. But a lot of people still get caught out when they post a duplicate-titled section. And what's the convention when you want to fix the section title, like here where I'd quite like "Opnions" to read "Opinions"? ;-) BLongley 18:12, 5 August 2009 (UTC)
I'll describe the issues related to section editing, headers, and summaries. Thanks for pointing out a gap. -DES Talk 20:31, 5 August 2009 (UTC)
See Help:Edit summary#Section editing. -DES Talk 21:03, 5 August 2009 (UTC)
Changes made to Help:Conventions. Do they cover the matter? -DES Talk 21:19, 5 August 2009 (UTC)
Oh and if your section edit changes the section title, change the summery within /* */ to match, and the new link will work (although old links for previous edits won't). -DES Talk 21:18, 5 August 2009 (UTC)

User page

Actually, one thing I'd like clarification on after seeing Jeremy G. Byrne's Wikipedia user page go read, it's fun). As it's a user page I think it would be fine if an ISFDB editor created such for him/herself only, in his own user area - we vary an awful lot on how much we reveal about ourselves - but this might conflict with advice on excessive biblio pages for authors. Some editors are authors too, but I think "use your 'own space for what you like (within reason)" can coexist with Author Bio Page rules. BLongley 18:26, 5 August 2009 (UTC)

I have, in the past, removed what amounted to self-blurbs from User pages, for example this edit and this edit. I hope no one would think that this sort of thing was proper in user space. I would have no problems with something like the Wikipedia user page you point to, although most editors here probably won't go to that amount of trouble. -DES Talk 20:31, 5 August 2009 (UTC)
While What the ISFDB Wiki is not discourages advertising of books, etc. It's silent on advertising for authors. The convention's page can remedy this by asking that authors, artists, and others that are listed in the ISFDB database should use the "Bio" page though can link to it from their user page. If someone is unpublished but is working in specfict then their user page bio must follow the guidelines listed in {{BioHeader}}. --Marc Kupper|talk 04:01, 7 August 2009 (UTC)
Ok I can add language to that effect. -DES Talk 13:16, 7 August 2009 (UTC)
Language added, is it ok? Also I have proposed to add anti-advertising language to Help:Contents/Purpose, for details see Help talk:Contents/Purpose -DES Talk 13:44, 7 August 2009 (UTC)
That looks good. It's getting late for me but something I want to tweak in a gentle way is to have the biography policy and guidelines in mind, or even to apply, for all user pages. I need to read through those bio/guideline pages to see if it has wording that does not make sense for user pages. --Marc Kupper|talk 10:01, 8 August 2009 (UTC)
I think the insistence on "professional tone" and "factual" need not apply so strictly, at least to the user pages of people who are actually editing the ISFDB, and are thus using their pages to identify themselves to other editors. A more jokey or personal note might be acceptable in such cases that I would think acceptable on a bio page, which the world is invited to read via a link from the author's db record. It is really only the "no advertising" and "no reviews" part that need apply to user pages, i think. -DES Talk 14:18, 8 August 2009 (UTC)
Thanks, I looked at again and the final two paragraphs look good. I'm really struggling with the first paragraph. It gave me a large headache and I need to take a break. DES, can you change the "User ID" to "Username"? The user_id is a db field that contains a record number. You can view your User ID on the Special:Preferences page. Something that's harder to clean up is that the word "user" is used in five different contexts within the first six sentences and it's this that's giving me the headache.
Something that's different about the user page section vs. everything else in conventions is that it's about content where the other conventions are more about behavior. Also, blank (red link) user pages are common enough that they likely qualify as a convention. --Marc Kupper|talk 01:12, 9 August 2009 (UTC)
Thank you David. The revised section is much easier to read. I also updated the user talk page section to use username. --Marc Kupper|talk 08:10, 9 August 2009 (UTC)
I'm glad you like it. Frankly I preder "UserID" to "username". The majority of sites that I have had accounts with call such a string used to login and to distinguish one user from another a "UserID" ("screenname" is probably second), in part because it need not be a name at all, but does identify a user. In our help pages, it is pretty much always called a "UserID" whenever it is referred to. While there may be a db field called "user_id" that is only known to those who work on the inside of the db -- to most users, even technical users, the UserID is the login string that goes with the password. Havin g said all that, i won't argue further. -DES Talk 14:35, 9 August 2009 (UTC)
My comment about the UserID was likely a reaction to trying to mentally parse through the original text. It had "User Page", User page, user page, User ID, UserID, userID, User, user, Sub-page, and subpage. There were too many variants for the old brain to process in a single paragraph. A stack overflow triggered a double-fault and left me thinking of the benefits of vacuum tube logic though overheating and moths suddenly become a hazard. I then took a look at the ISFDB login and account creation pages to see what the usage was.
I took another look and cleaned up the wording usage so that capitalization, word order, con-tractions, etc. are consistent. --Marc Kupper|talk 01:23, 10 August 2009 (UTC)

Ready?

(unindent) Any further comments? Anything else left out? Any objections to this going live? -DES Talk 16:12, 6 August 2009 (UTC)

It all looks good to me. --Marc Kupper|talk 08:11, 9 August 2009 (UTC)
I can't think of anything to add at this time, and i believe that all objections or comments have been addressed. While no help page is ever graven in stone, i think this might be ready for the "Not Final" header to come off. Does anyone object? Does anyone have further changes or additions to suggest? -DES Talk 21:05, 10 August 2009 (UTC)
Done. --Marc Kupper|talk 17:23, 11 August 2009 (UTC)
I have linked this to a few places in the various wiki help pages. Should it also go in {{Welcome}}? -DES Talk 17:42, 11 August 2009 (UTC)
I'd say yes on {{Welcome}} but then looked and it already has a rather long list of things. How about on the right side of Help:Contents just under "Policies and guidelines?" and we'll add conventions to the welcome message as part of a tuneup of that page? I have not been keeping tallies on what new editors are doing though am aware that time seem to fail to notice they have a talk page. --Marc Kupper|talk 19:30, 11 August 2009 (UTC)
I've put it on Help:Contents as you suggested. I did rather draft the thing with Welcome in mind, and our welcome is still far shorter than Wikipedia's. But we can take time to think about that. -DES Talk 20:13, 11 August 2009 (UTC)

Minor edits

split off from thread above. -DES Talk 19:27, 7 August 2009 (UTC)

Would this conventions page be a place to mention the use of the "minor edit" flag, which was discussed on the moderator page? MHHutchins 18:10, 7 August 2009 (UTC)

Good idea. I will add such a section. -DES Talk 18:40, 7 August 2009 (UTC)
Section added. -DES Talk 19:27, 7 August 2009 (UTC)
This looks find though the part about "Any change which is at all likely to be controversial..." seems redundant unless I missed something. What got my attention there is that it lists three specific types of pages, "policy, help, or discussion page", and yet we have many other pages such as user, author bio/bibliography, series, publisher, general information, etc. Is there something special about policy, help, or discussion pages with respect to the minor edit flag? If not, I'd move to strike "policy, help, or discussion" from that sentence. --Marc Kupper|talk 09:42, 8 August 2009 (UTC)
Pages like Policy, Help, and discussion pages may well affect the project as a whole, or a significant section of it, so IMO changes there are particularly important, while user, author bio/bibliography, series, and publisher pages are more local -- changes to them are not unimportant, but are not so widespread, in my view. That is why I singled out the pages I did. But let me reword a bit. Also, this is a section where to make things clear I am willing tom accept a bit of redundancy. Actually, IMO the bit about "Any change which is at all likely to be controversial" is the heart of the standard. the rest is largely elaboration and example. -DES Talk 15:03, 8 August 2009 (UTC)

Editing the User Page Associated with Another User

split off from thread above -DES Talk 17:52, 7 August 2009 (UTC)

I would question the ambiguity of "Except to deal with violations of these principles, it is not usual for an editor to edit the user page associated with another user, except by request of that user" with the later statement that a user page "may be freely edited by all editors if there is a good reason." I think the latter statement pretty much gives license to anyone who has a personal "good reason". The first statement gives only one reason "to deal with violations". MHHutchins 15:14, 7 August 2009 (UTC)

The intent was to say that such edits were unusual but not forbidden. I'll try to refine the wording. -DES Talk 16:07, 7 August 2009 (UTC)
It now reads "...may be edited by any editor if there is a particularly good reason. Such edits, however, are quite unusual." "freely" has been removed. how does that sound? -DES Talk 16:15, 7 August 2009 (UTC)
Removing that word ("freely") is an improvement, but it might be better to bring those two sentences together, giving the exceptions in the same place. MHHutchins 17:17, 7 August 2009 (UTC)
How about this:
"Even though we speak of "his user page" or "Joe's user page", keep in mind that all Wiki pages, including user pages, are provided to serve the purposes of the ISFDB. These pages belong to the project, and not to any particular user. Except to deal with violations of those principles stated above or by request of the user, editors should be cautious about editing the user page associated with another user. Any disputes about such edits can be brought before the community forum."
MHHutchins 17:29, 7 August 2009 (UTC)
That works for me. -DES Talk 17:52, 7 August 2009 (UTC)
Changes made. MHHutchins 18:10, 7 August 2009 (UTC)
Yep, that looks good. --Marc Kupper|talk 23:53, 8 August 2009 (UTC)

Editing Help pages

I'd prefer that the Editing Help pages section lean towards Wikipedia's "be bold" editing guideline than the "use restraint and discuss first" emphasis. Part of the reasoning is that it's sometimes hard for a person to visualize the impact of a particular change until they see it in action. A secondary issue is that many threads drift around without resolution. Thus, be bold, make the change, and, while you can defend it on a talk/discussion page, don't get emotionally attached to it. --Marc Kupper|talk 03:40, 7 August 2009 (UTC)

This is so strange that I've had to read it more than once to make sure I understand your intentions clearly. You believe that it's alright for someone to change anything in our Help pages and then wait until after the change is made to defend it, and then only after someone else stumbles upon it and questions it on one of the community pages. The perfect defense would then be "it's already established in the help pages". I think you're missing the meaning of Wikipedia's Be Bold statement. They're talking about updating the encyclopedia pages. I wonder how fast that philosophy would last if someone tried to change any of their Help or Policy pages. Talk about "visualizing the impact"! MHHutchins 04:42, 7 August 2009 (UTC)
This "restraint, discuss first" policy is copied closely from Wikipedia's custom about its policy' and guideline pages, to which the help pages here more closely correspond, IMO, Furthermore, one reason behind the "be bold" philosophy is that Wikipedia retains pages histories forever, in the usual case. Thus it is easy to see who made any particular change, and how and when the current state of a page was arrived at, making undoing "bold" actions when needed easier. I might also add that in the past, when I changed help after a discussion that I thought had reached a consensus, others said that they would have preferred to be explicitly told that the help was going to be changed, in advance, as they might not agree with the change. Thus it appeared to me that the "restraint first" is how we actually operate. How many times has an R&S or CP discussion ended with "Are we agreed? Any objections to changing the help now?" or words to that effect? Lots, IIRC. -DES Talk 13:09, 7 August 2009 (UTC)
I think that "be bold" is fine when fixing grammar/spelling on Help and Policy pages, but it wouldn't be appropriate when making substantive changes. (And we really need to make sure that our Help pages are internally consistent and not redundant.)
As an aside, Wikipedia's rules and guidelines have become quite complicated over the years. Managing large distributed projects with thousands of contributors whose identity and credentials cannot be easily verified is a new area of project management and we are still learning how to handle this beast. Wikipedia's growing pains have been considerable -- some of them are explained in The role of policies in collaborative anarchy -- and they are still struggling with the process, constantly coming up with ways to handle complex issues, e.g. the BOLD, revert, discuss cycle.
As far as "Be bold" goes, it was, to a significant extent, a reaction to the failures of more structured and slow-paced approaches, e.g. the failure of Nupedia. To the extent that it encouraged new editors to get involved starting with minor spelling and grammar fixes, it has worked well. However, the part of the policy that encouraged users to [boldly] "add facts" was less successful, which is why the policy is qualified with "but please be careful" and "but do not be reckless". In addition, Wikipedia now requires Verifiability, which is in constant tension with "be bold". There are other, more fundamental, issues with Wikipedia, but we don't need to go there at the moment. Ahasuerus 15:52, 7 August 2009 (UTC)
The Help:Conventions page is an example of something minor that could get added to ISFDB without prior discussion. The current practice is to put {{NotFinal}} on all new content and it's worded so that the default is that the content "has not yet obtained a solid consensus" and "This notice will be removed when the page obtains a reasonable consensus on its contents." It's fostering a sense of WP:OWN in that editor's need to get permission from active participants (usually moderators) to make these non-substantial changes.
I'm advocating that the default be an assumption of consensus. For example, with {{NotFinal}} it would be "This page, or text, was introduced to ISFDB on day Monthname year. Please be aware that it's still being polished. All editors are welcome to contribute to this page and to it's talk page." The main difference is to shift the default away from "we don't have consensus." If an editor sees a serious problem developing with the new content they can hat it with something like {{Problem}} or {{NeedConsensus}} that would say "An editor has seen something that he or she believes is a significant issue with the content of this page. Please see link to talk page section for a discussion about this. Please be aware that there may not be consensus on some of the page content."
If someone has a substantive shift of policy where it seems likely that a NeedConsensus hatting will be used then yes, it's a good idea to ask, "this is something I have in mind. Does anyone see a problem with it?" Take a look at Wikipedia's Policies and guidelines article which covers editing policy itself and says
"Such pages are taken to be accurate until a consensus process involving the general community shows otherwise. Editors should take care not to avoid making substantive changes, but are encouraged to boldly make policies clearer. Editors are expected to use their common sense in interpreting and applying these rules; those who violate the spirit of the rule may be reprimanded even if no rule has technically been broken."
The implication is the default is consensus unless the general community shows otherwise. The editor "M" has been able to significant rewrite of the article in the past two weeks. Obviously a rewrite of WP's core policy article has generated some talk page discussions and M is working with editors both on the talk page and in his edits to the main article. Had M needed to get consensus first it could have been decades before the article was rewritten. ISFDB is smaller and so we are only looking at a few weeks or months instead of decades but I don't see that as cause for the no consensus default. Sure, people will occasionally ask "did you really mean that?" and for the most part, WP and ISFDB have shown these queries are dealt with civilly even when it's apparent parties disagree. --Marc Kupper|talk 18:12, 7 August 2009 (UTC)
It's good to see that you slightly amended your original statement about being bold in changing help pages (I think), and directed it specifically toward being bold about creating pages for new areas of concern to which the {{NotFinal}} header can be added, making it clear that a consensus has not been reached. The default on these pages should be "don't take this page for gospel". Once that header has been removed, it becomes the standard from which later arguments can be made either for or against. In other words, nothing is truly permanently gospel, but calcification occurs almost immediately. Who wants to enter hundreds of issues of magazines, only to find that the standards have changed? (You mag guys know what I'm talking about.) In the example you provide about the updating of an article by editor M, you say that it might have taken decades waiting for a consensus. In most cases, I would disagree (except in the case of my own bold move, later on that.) Consensus sometimes means that two or three editors feel more passionately about a specific concern than all the rest. You can agree that most ISFDB editors rarely get involved in such discussions, leaving only the few that have strong opinions on the subject deciding how the others will edit. (Which probably makes the results more thought out, than say, a presidential election.)
Still, there is one real-life example of your boldness argument actually occurring. After months of asking about how we should handle SFBC editions, and getting practically nil response, I boldly went where no man has gone before, created a set of standards, announced those standards, got very little feedback (one question and one compliment), and now those standards are part of the help pages. If I had gone through the process that I'm advocating (proposal, discussion, consensus) it might have taken weeks. I see and agree with your points to a certain extent in the creation of standards for heretofore unknown or unexamined areas. But I still do not think that the general help pages should be changed before some discussion has taken place. MHHutchins 05:30, 10 August 2009 (UTC)
I will alter the text indicating a different approach to newly drafted help pages. I will mention {{NotFinal}}. I will also suggest creating alternate draft pages when major changes are under discussion as a possible method. -DES Talk 16:19, 10 August 2009 (UTC)

Edit Summaries and Section editing

This section has a level of instructional detail that seems out of place compared to the rest of the page and does not seem like a "convention." I can't say I've given a lot of thought to the minutiae of dealing with sections with the same name. :-) --Marc Kupper|talk 03:51, 7 August 2009 (UTC)

I was explicitly asked (by Bill Longley, in the early part of this thread) to include detail on how to deal with these issues. I can move this detail elsewhere and retain only a briefer guide and a pointer, if you want. Where do you want the detail, which has been asked for? -DES Talk 13:13, 7 August 2009 (UTC)
I agree with Marc that this level of explanation should not be on a conventions page. Is it somewhere in the Wiki editing help section? If not, that may be a better place for it. Also, I'm assuming this page is for Wiki editing conventions and not database conventions (such as the courtesy of notifying verifiers of changes to pub records.) Is that right? MHHutchins 15:02, 7 August 2009 (UTC)
It is put together from, and to some extent expanded & clarified from, stuff in a couple of different wiki help pages (which are linked). I'll see about finding a proper place in the wiki help to move it to, with a pointer left on the conventions page. Does that suit in principle? -DES Talk 17:49, 7 August 2009 (UTC)
Done. Wording seem good people? Further suggestions for improvement? -DES Talk 18:39, 7 August 2009 (UTC)
Though I didn't want to I added some more "user instruction" to the edit-summaries section, took a look, and then whacked the entire section to focus on convention. Any instruction and detailed explanation is left for the edit summary help page. --Marc Kupper|talk 19:08, 7 August 2009 (UTC)
I think this whack was a mistake. I won't revert, but i ask others to consider whether the more detailed version before that edit, or perhaps the one achieved in this edit isn't better. Explaining a little bit of how this feature works is IMO helpful for explaining that using edit summaries is our convention, and why. At the very least, I'd like to restore the text that describes where edit summaries appear, and a 1-2 sentence mention of section summaries, and that it is our convention to leave the automated summaries in place. -DES Talk 19:19, 7 August 2009 (UTC)
I'm trying to include the whacked text on the Help:Edit summary instructional page. At present the lead of that page is pretty choppy and I've run out of time to do the thinking needed to tidy up the lead while also including the whacked details either in the lead or on the page.
I saw the list of every single possible place/way edit summaries appear as a distraction from the "conventions" emphasis. User instruction does not need to be exhaustive. That's left for reference manuals or perhaps an "advanced editing" section where a user interested in such can learn the secrets of wiki wizarding.
You had a good point about conventions section edits and so added a line explaining that those too need edit summaries beyond the default summary. --Marc Kupper|talk 19:42, 7 August 2009 (UTC)
That is all very well -- that page, which started as a copy of the mediawiki help page, could probably use improvement. But I still think that a little more detail is desirable on the conventions page, because some users, particularly new ones, won't follow the link. And the mention of the two most important places where edit summaries appear to my mind is a significant part of the answer to "why bother with them at all?" -DES Talk 19:53, 7 August 2009 (UTC)
People that won't/don't follow links are also likely the same ones that won't/don't use the watch/change/history pages. :-) The current text that explains where the summaries get used is good. --Marc Kupper|talk 23:40, 8 August 2009 (UTC)

All pages belong to the project

The caution about User pages and user talk pages not belonging to the user is intentionally duplicated (with minor appropriate differences) under the User page and User talk page sections. This is because these are the two pages generally spoken of in the possessive ("Joe's User Page", "Sarah's talk page") and that users have been apt (both here and on other wikis) to think of and speak of as "my page" and incorrectly expect to have total control over. I wanted to make it very explicit that the "All pages belong to the project" rule applied to both user and user talk pages, and was not missed by someone just reading the section applying to one of these. Given that purpose, does anyone still object to the near duplication remaining on the page? -DES Talk 13:32, 7 August 2009 (UTC)

I had removed the text as it was a full duplicate and appeared to be an editing accident. The new wording you used is fine. --Marc Kupper|talk 16:43, 7 August 2009 (UTC)

Move this to the Conventions's talk page

Can we move this block entire discussion about the content of Help:Conventions to Help talk:Conventions and to just leave a link to it here? That way the history of discussion about that page is on it's talk page rather than eventually being buried in the Community Portal archives. --Marc Kupper|talk 19:49, 7 August 2009 (UTC)

Will do. Good idea. -DES Talk 19:53, 7 August 2009 (UTC)
Done. -DES Talk 19:58, 7 August 2009 (UTC)

Splitting or moving a discussion

I have added a section on "Splitting or moving a discussion". There is a bit of "how to" to it, but in this case the how-tos are largely a matter of convention, so I think they may belong here. Or I could create Help:Splitting or moving a wiki discussion and simply have this be a pointer and a mention of the note that should be left. Any thoughts? -DES Talk 20:24, 7 August 2009 (UTC)

One thing I saw in the current wording is that it's not clear what the conventions are. I believe they would be:
  1. Editors can split or move a discussion if it wanders far from its original topic, a distinct sub-topic emerges, or if there's another page that's a much better fit for the discussion topic.
  2. Splits, copies, or moves must never be done in an attempt to suppress or support a particular point of view. If in doubt then obtain consensus first regarding how the discussion should be handled.
  3. We generally ask or announce first before moving a discussion. Advanced notice is generally not used when splitting a discussion on the same page or copying part or all of one.
  4. When discussions are copied or moved to another page we add a note explaining the copy or move and that includes a link to the new location. Likewise, at the new location we start with a note explaining the discussion was moved or copied from a prior page/discussion and link back to the original discussion section. Forward and reverse links are generally not used when discussions get split on the same page.
I don't think it's a convention yet that we do the moved/copied message in small type though editors should be aware they can do this. If the idea catches on then it becomes a convention. --Marc Kupper|talk 23:22, 8 August 2009 (UTC)
Well its how I always do it, adn i think I've doen the vast majority of splits and moves of late. I thought others were imitating me. I propose declaring it to be a convention henceforth. -DES Talk 04:58, 9 August 2009 (UTC)
There's one more convention that'll take a bit of explaining which is the nuances of copying parts of a prior thread to give a new section or sub-section context and also if and when we remove the indenting as part of this. I believe item #2 above is the general convention that covers these nuances and so I doubt this needs to be covered as a separate convention.
Thus I'm proposing that the content of the conventions page just list the conventions and that there be a fairly detailed instructional page that explains how to do this. --Marc Kupper|talk 23:22, 8 August 2009 (UTC)
Hmm maybe. -DES Talk 04:58, 9 August 2009 (UTC)
I created Help:Splitting or moving a wiki discussion, starting it as a clone of the section here, and expanding it a bit. I edited the section here, removing some of the "how-to" aspects and using much of your text above, with some additions and alterations. See what you think. -DES Talk 16:11, 10 August 2009 (UTC)
I did a fast read and it looks good. --Marc Kupper|talk 20:58, 10 August 2009 (UTC)

Wiki vs DB conventions

I think someone asked (but I can't find where) if this page was intended to be solely about wiki conventions, or if b conventions, such as notifying a verifier of changes to verified pubs, should also be included. As currently designed, this page is only about wiki conventions. There seem to be enough of those for a full page. It would be possible to add db conventions to this page, but I am inclined to think it might be a mistake. Or this page could be moved to help:Wiki Conventions, and perhaps a parallel Help:Database conventions could be created. But I think that most of the database conventions are mentioned somewhere in the existing help, and when you think about it, most much of what the existing database help describes are conventions, which would make any such page too big. Still we could list some key database conventions on a database conventions page, if people think that would be worth while. -DES Talk 20:33, 7 August 2009 (UTC)

One db convention I could see as part of this page is to ask editors that submit changes to also be checking their user-talk pages and responding to comments left there per Help:Conventions#User talk page. Beyond that, db conventions would seem to be a summary of the existing db help. --Marc Kupper|talk 22:30, 8 August 2009 (UTC)
Done. -DES Talk 14:39, 9 August 2009 (UTC)
I agree that moving this to Wiki Conventions is a good idea as then the page title is less ambiguous. --Marc Kupper|talk 22:30, 8 August 2009 (UTC)
Does anyone else support such a move? anyone opposed? -DES Talk 14:39, 9 August 2009 (UTC)
I agree with Marc that the title of this page be changed to Wiki Conventions. It answers the question I raised (yes, it was me) about whether db conventions should be added to this page. I realize now that those conventions are stated (but interspersed) throughout the help pages. MHHutchins 16:58, 10 August 2009 (UTC)
Very well, I'll move it right now. -DES Talk 17:05, 10 August 2009 (UTC)
Move done. -DES Talk 17:06, 10 August 2009 (UTC)