This page is a part of the Wiki Community set of pages.

Add new proposals and suggestions for the Davis Wiki here. If you are commenting on another's proposal, it may be better to edit the page and add your comment below theirs. If you're proposing something having to do with the software or site itself, try the Wiki Community/Technical Discussion entry.

Proposals

You must be logged in to comment on this page. Please log in.

For older comments, please see the Wiki Community/Proposals/Archive page.

2008-06-12 17:45:14   I propose that editors wishing to link to California Aggie articles should use archive.org links when available. They are definitely more stable in the long term than californiaaggie.com links. All californiaaggie.com links have broken at least twice in the life of the wiki. —WilliamLewis

  • Why shouldn't the Aggie feel some responsibility to provide archival long term links to their stories? —JasonAller
  • Not a bad idea, but I can see the Aggie actually asking for Archive.org to remove their history. Blearg.

2008-06-26 22:36:20   One-hit-wonder accounts that come through and bash a business have been a problem for quite awhile. Clarity Massage worries me a bit more than most, though. An anonymous poster with no history (and thus reputation) came through and posted unverifiable allegations of illegal activity instead of reporting it to the police, who actually have the resources to investigate the complaint. It looks like this comment has lead to the business losing at least one customer. I don't know what we need to do, but something does need to be done. At the very least, I think someone who wants to allege such things should have the police department pursue this and/or stand behind their real name so the business has a chance to defend themselves if their comment is allowed to remain. Any ideas? —WilliamLewis

These drive me nuts. Another massage business was directly accused of prostitution here. That comment still stands. Restaurants are routinely accused of violating health codes ("I found a bug under the food") without proof — the most damaging thing you can say about a restaurant. An auto repair business yells at customers (doubtful) and degrades women (more doubtful). No details, just accusations. But if the business owner were to remove the posts, they would likely be restored. Basically, IMO, if the comment implies or accuses, without any detail or evidence, something that is against the law, that accusation should be removed by one of us. Also, personally insulting comments should also be removed. I don't think the Davis Wiki exists to facilitate harm to local businesses. But I have a clear bias on this topic, so it would be useful for others to weigh in on it. —DonShor

There's another discussion of this at Wiki Community/Reputation. I've been tagging one hits with the phrase there (so I pull them back up at a future date). —jw

2008-06-29 00:17:37   Proposal: create a page flag for pages that contain time-sensitive information or are out of date. This way it would be easy to 1) track pages that become outdated frequently, and 2) help individuals communicate easily that information may be wrong, despite the fact the individual may not know or know how to obtain the most up-to-date information.

I would do it myself if I had a modicum of an idea of where to start, but perhaps this would be a task best left to someone with actual programming experience. —MaryLieth

2008-11-18 19:01:55   Why doesn't the DavisWiki.org site offer a discussion forum area? While this is a GREAT site, and also very useful, it would be even better if there was an area to start threads and discuss information related to Davis. Ideally, a phpBB forum or a vBulletin forum would do the trick.

Some uses might include the posting of jobs, local classified ads, community proposals, etc. I think it could be a great way to communicate about topics without having to hunt for something specific in the Wiki. —BrettW Discussions can be carried out using page creation and or subpages instea of using phbb or vbulletin... Daubert

2009-04-14 12:31:38   Can we make it so that the search box is highlighted when i open the main page? For example, I go to Davis Wiki and I can immediately type and search instead of having to click the search box. As far as I know, most people use the page to search, so this makes sense to me. As for the people who aren't searching, you can scroll with your mouse anyway. It shouldn't be too hard to make this change right? —quadshock

2009-05-05 14:31:25   How about a feature to mute certain pages from the recent changes (cf. some of the changes on/around May 5th). —TheAmazingLarry

  • You mean like the "Clear Observed Changes" button on top of the Recent Changes page? —BrentLaabs
    • No, I mean to mute the changes to individual pages. For example, I'd like to stop seeing all the back-and forth exchanges like that on RealComputers.
      • Generally stuff like that only happens a couple days, once or twice a year. The "anti-bookmark" feature has been proposed in the past, it just needed so rarely I don't think it's been high priority. If you code the feature or find somebody willing to code it for you and it doesn't suck up CPU time, I'm sure it would be added, however. —jw
        • How can I go about that? I mean, assuming I can chisel out some free time to do it... :(
          • Sycamore is the dev wiki for Wiki Spot. Developers wanted! I also came up with a nice variant that would keep most of the chatter down (other than the actual edit wars before they get routed to Talk pages). Modify [[RecentChanges]] to have a version that omits Users/* and */Talk entries, a la how [[WantedPages]] omits User/* by default. That should be just about as fast as a normal RecentChanges call, minus the overhead in displaying to conditionally display based on the entry id. Most of the content free back and forth is on Users/* anyway. —jw

2009-06-15 13:59:58   I'd suggest the addition of discussion threading to the wiki code. We often have very complex discussions, but tracking and updating threads can be difficult, especially for non-advanced users. This might be accomplished with an edit thread button if you click on a specific thread, for example. Time stamping of all posts, not just main ones, could also be helpful here. —IDoNotExist

What steps have you taken to implement this? How do you imagine it working with existing markup? —NickSchmalenberger

Me personally? Nothing. I don't work on wiki code. I just thought it might be useful as it solves a problem that I frequently see on here... —IDoNotExist

2009-08-12 01:30:38   I think it might benefit the wiki to change the text for the "delete page" option (when editing a page) so that it actually says "delete page" on the button, as opposed to the current "delete". I've seen a few people who accidentally delete a page when they mean to revert their most recent edit, and I think it's because the current setup does not actually explicitly tell the user that it is a page being deleted. —JoePomidor

  • In addition, the Revert button could have the button-label text changed to "Undo". I think that would really be far more user friendly. -ES
    • Bad idea, because reversion and undoing are different things. A revert takes the page back to a previous revision. Undo undoes a specific edit and that edit alone. (Sycamore doesn't implement undos in a way normal users can use them)—wl
      • Actually, I had thought there was a "Revert" button between "Delete" and "Rename" in the box under the changelog. There isn't, so indeed it would be a bad idea as stated. Unless, we add in said button. Right next to "Delete" have a "Revert to Last Version" button or something. Sort of like a quick revert, so that people don't click "Delete" (and most people won't click "Info" to go to the actual 'reverts'). -ES
        • Do we need to make reverting any easier? I think there is quite enough of it as it is. —JasonAller
          • That sounds like it disregards legitimate uses of it, which is the entire context Joe brought up the accidental page deletions. Worrying about whether it might make it easier for a revert war seems silly; someone would have to hit the edit button and then go down to the button to click it. It'd still be faster to hit 'info' and move your cursor an inch down the screen. But said button would be pretty friendly to new users in particular, who seem prone to deleting entire pages thinking it'll undo their last edit. Changing Delete to Delete Page might help avoid this, but it won't help people who aren't used to editing entries and only use the comment box to input. I really doubt this would have any bigger effect on the wiki than those uses. -ES
  • Back to the original idea: This is a one line change to PageEditor.py, and I implemented in less than a minute on my testing box. The question is: will this actually help people out, or does it just make more clutter? Here's what it would look like:

Current:

New:

—BrentLaabs

2010-01-06 09:21:01   Please please pleas can we have a longer comment-edit box? I frequently have to type very short strange messages trying to get my entire point in. —WesHardaker

  • Ditto. —CovertProfessor
    • I'm not sure that that would make sense... it is long eno -jw
      • It's especially hard for the rever -cp
  • You're not supposed to be able to write essays. It's for a quick comment and nothing more. If you have to do more explaining than that then it's likely something complicated enough worth explaining on a discussion page, etc. —PhilipNeustrom
    • It would also make the info page much harder to read if they weren't very concise summaries. Actually, the more I think about it, the short form seems to be salt, subtly encouraging a positive behavior through a limitation. If they were too long, people also might start to trust them... On a side note, there is a reliance on deleted content never being wiped (i.e., the assumption that a deleted Talk page will always be available in the future) that worries me a bit, as that's not a openly stated fact, but rather a working assumption. Digging through the history of an entry might be tough if the corresponding Talk entry's history is permadeleted. -jw
    • Another hundred characters wouldn't hurt brevity too much. —wl
    • Indeed, I wasn't thinking of essays, just making them a wee bit longer — say, 50% longer. —cp
      • It's 80 characters right now. I'm now pondering: What would 120 look like on the info and how much would it help communicate the edit over what already exists? -jw
        • It's just a feeling for how the length works in practice — that I often end up shortening what I want to say and have to do it by sacrificing communication. As for the info page, for those with wide screens who keep their browser windows wide it would be fine, for others it wraps. Doesn't look too bad w/a wrap, imo. —cp
          • The main issue I run into is having to describe why I'm making the change, etc, but simply don't have the characters to fully describe it. The result is an underdescribed version of what I want to say, and just as cp indicated you end up sacrificing communication. Just as all VCS's (and a wiki is a special form of a VCS) allow full text describing an edit to be attached to the edit itself, we should too. Talk pages don't cut it for that. —wh. (on a side note, I think this has been the funniest commit message comment series to ever follow)
            • Yes, but the info page should be terse, IMO (and it's only one O). It's also an opinion that I'm uncertain of... I think around 120 characters or around 8k characters are likely two different sweet spots, but long essays about edits would radically change the dynamic of an info view. There's also another kind of nefarious reason to keep the edit comments down — so they don't become a haven for spam. -jw
              • Spam edit comments can be easily memory-hole'd. —wl
                • I'm talking about legitimate edits with cause or profit spam. The ability to a paragraph into every edit might tempt some people to just always paste in their rant about the president or how good or bad their experience with a random restaurant is. And even worse, new editors might well think that's where you're *supposed* to type a review or update. I certainly already abuse the edit comments for fun, and I've seen others do so as well. -jw
              • The 140 character twitter message length could be a useful guide here. But perhaps we would be better served by requiring all edit messages to be written in the form of haiku, or as short, iambic pentameter poems... (Seriously, anything longer than 140 characters is probably going to introduce readability issues, because it will be longer than a typical browser width. This might even be a good argument for 120... —IDoNotExist
              • Actually, now that I see my own comment on there, I think it should actually be no more than 120, because you need room to include the user's name tag too, whilst still being readable... —IDoNotExist
                • 80 and 120 are common for hysterical raisins... err... historical reasons. They were common column widths for screens and printers, and were quite useful for single line comments. A boost of 50% probably would allow all the comments I've ever been cut off on, but I'm not advocating 120 over 140... it's just an arbitrary "seems about right" number. -jw
                • Here is an example of 140 + signature (out of outline sequence to show proper alignment with the browser edge). Note that these examples do not include the indentation that the wiki already does, so the available space without a line wrap is even worse...:

this is 140 please note the signature on the end changes the total length to 140 + some arbitrary value that is longer than 140. For examp —IDoNotExist

  • Here is an example of 120 + signature (out of outline sequence to show proper alignment with the browser edge):

this is 120 please note the signature on the end changes the total length to 120 + some arbitrary value that is longer t —IDoNotExist

  • I prefer it to be short. I think we've quite often been using it as more of a conversational tool ("hey, anyone want to edit blah blah?") and similar comments to each other, communicating via the recent changes tab rather than direct one-to-one or utilizing talk pages. I agree with Philip, in that I like it to be shorter. While we often have mini-convos that are typically only viewable through the 'recent changes' tab and sometimes a page info, I suppose we shouldn't. I like keeping it to the summary about the edit. ("rewrote intro,changed picture formatting, and replied to Steven's comment" is 73 characters....) If we're making so many edits that we can't summarize it in one line, perhaps that one edit is too large. I've noticed JabberWokky for example sometimes makes two, three or four edits rather than one large massive one. It's easier to follow what's changed, and it makes it easier to redo or undo or dispute any one part of it. I think that's excellent editing practice, and much preferred over one massive page rewrite. In my opinion, the topics I've mentioned go hand-in-hand. The length of the edit comment affects the way it's used, and I think keeping it shorter is more likely to encourage good editing practices. -ES

Let me add a further consideration. I can't tell you how often I start to type my reason, only to find I have to find a shorter way of saying it. Then I have to think about synonyms, abbreviations, other ways to word, etc. This happens to me often and frankly it's a waste of my time. With a little more space I could just type what I wanted to say and move onto something more productive, like editing a different wiki page. :-) —CovertProfessor

  • Although this is a very small group discussing the issue, it seems at least some people agree with the idea that 80 characters is at least constraining. Anybody have a strong case for 120/140ish versus allowing "paragraphs"? I dislike the latter idea (although it makes sense with VCSes, I'm not certain that the types of edits the wiki usually has would benefit, and I think it would make a scan of info more difficult). By the way, a non-trivial change would be the ability to add comments to file uploads, which I would really like. I think that would have to be post-rewrite. -jw

Assumption check: Hey, by the way, I think most people are assuming that extending the field would be easy — that the database is either already able to handle longer comments or it is trivial to alter table, and that changing a couple integers here and there will allow longer comments... anybody want to wade into the code or does anybody know off hand if that's the case? -jw

  • A paragraph would quickly make the recent changes page unreadable. It's important for people to be able to scan through the page quickly to see what has changed. The comments provide a useful guide to see if the change is relevant to the reader. But too long of a comment would make it unreadable. Keeping it at one line is a good thing. (Note: perhaps the line could be in a different font or have a different background, or show up in a different column as in a table. That would make it more readable. In fact, with a table format, it might even be feasible to have 2-3 lines without hurting readability too much, so long as the top of the comment and the change info appear on the same line.) —IDoNotExist

Trying to pull in everything I just read, it seems to me that everyone(ish) agrees that a paragraph is too long. It seems that most people think 120 or 140 is a good compromise. For those that think 120 is too long, explain why 10 is too short now ;-) Or doing away with comments altogether! </troll>. Somewhere we need to strike a balance between helpful and hindering. I propose we bump it to 120 (not I wanted to say 140) and see where that leaves us. — WH

  • Careful, at this point 'everyone(ish)' is only 3 to 4 people and at least two people expressed the desire for it to stay the same :P
    • That's why I said in my summary above "Although this is a very small group discussing the issue, it seems at least some people agree with the idea that 80 characters is at least constraining". I'm not sure there's many people who care, however. Or at least until it changes, and then there's a hue and cry to tar and feather the person who changed it. ;) -jw

2010-01-07 08:33:16   Would it be possible to choose a specific format for posting business hours - and using a bot to fix entries? Right now many businesses have completely different capitalizations and dashes etc.

I'm not familiar with bots, but the craziness that is business hours formatting is out of control and could use some touching up. —TJJ

Are there any reasons why this is a problem? I don't see this as being a big issue. —wl

  • Different editors, different tastes. If you really care about it, it could be done... is there a reason I'm not seeing? -jw
    • Well we're talking about a common section on pages that isn't consistent. Obviously the information still gets across, but setting a standard would make the pages a lot cleaner and more readable.—TJJ
    • I think as long as the table for one location of a business doesn't take up more than 512 pixels or something and the length of the lines look ok together, its great. Having tables at all contributes to the homogeneity of the wiki, I think its mostly worth it, but for human reading I like having things a little bit mixed up too. —NickSchmalenberger
      • Personally, I think there's too much stuff in many of the tables that should be in the body or prose. Things like apartment features and possibly owner and established. Phone, website and such are quick pointers for more information, but when the info is all in the headers, it starts to feel like you're reading a spreadsheet when you're browsing the wiki. :) I'm not for getting rid of the info... the apartment features, for example, allow somebody to compare back and forth when choosing a place. I'm just saying that I think they would be better in a section under an introduction. -jw
      • I agree, its nice when complete sentences and paragraphs are used more to describe things. —NickSchmalenberger

2010-03-02 01:19:36   Is there a simple way to restrict the width of text displayed on a wiki page? A width of 66 characters is often considered the upper bound for easily reading multiple lines of text. Having a single long line on a larger monitor can make wiki entries particularly challenging to read, and it seems that most newspapers / blogs / etc avoid this. This would increase the readability of the wiki in general. It seems it would at least be useful as an option? Thoughts on introducing this as default format down the line? —Carl

There's a place for personal user styles in the user settings, or you can try Stylish. Though seeing that one needs to learn CSS first, I would not call that simple. In any case, yes, the line length has bothered me for some time as well (but apparently not enough to motivate me to write my own stylesheet yet). Would be pretty cool if editors can contribute their own daviswiki styles... —EBT

Your browser window doesn't have to be the full width of the screen, yanno.

2010-09-24 18:40:27   Lots of places (like Ken's Bike & Ski) have comments ranging back to 2004. I propose that comments older than 4 years be put into an archive page with a link on the main page. Reference example page: Cibon on RocWiki —PeterBoulay

  • No need to make a proposal — lots of pages on the Davis wiki do that. They are done in various ways; Raja's is one such example. All the other pages need is someone willing to do the work. Usually a page gets done when someone gets inspired for one reason or another. So, if you feel inspired... —CovertProfessor
Add tags