Tidied up highlighting past 80 columns tip
Ben Schmidt
I have tidied up this tip:
http://vim.wikia.com/wiki/Highlight_text_beyond_80_columns
but seeking comments/further work from others in the community.
Is there a way to draw people's attention to tips like this in the Wiki, (i.e.
ones where work has been done and further comments are sought)? Perhaps a way to
make a tip, whether a new one or a tidied old one, a 'New tip' candidate is what
I'm seeking, so they go through the normal review, etc. and then get given a
permanent ID.
Speaking of which...how does that work? A lot of tips that already have IDs are
rubbish. Do they still get to keep their IDs? Perhaps we should be, after
reviewing tips, giving them IDs in a new namespace with the eventual aim of
removing the old tip IDs completely?
Ben.
Matt Wozniski
> Is there a way to draw people's attention to tips like this in the Wiki, (i.e.
> ones where work has been done and further comments are sought)? Perhaps a way to
> make a tip, whether a new one or a tidied old one, a 'New tip' candidate is what
> I'm seeking, so they go through the normal review, etc. and then get given a
> permanent ID.
>
> Speaking of which...how does that work? A lot of tips that already have IDs are
> rubbish. Do they still get to keep their IDs? Perhaps we should be, after
> reviewing tips, giving them IDs in a new namespace with the eventual aim of
> removing the old tip IDs completely?
I definitely think that we should get rid of the tip ID system
entirely. It just doesn't make any sense on a wiki. In fact, I'd
argue that we should do away with it ASAP, and every time we can agree
on the title for an old VimTip we should create the article at that
title and keep the VimTip### entry only as a redirect to the Tip Title
one...
Anyone else who feels strongly one way or the other?
~Matt
Ben Schmidt
Sounds good. Only one concern: there should be a way to link to a tip by
URL with confidence that it won't change. So we need to have some policy
of "once a title is agreed upon, it can't be changed" (or only rarely
and with a redirect in place) or something like that.
Ben.
John Beckett
> I have tidied up this tip:
> http://vim.wikia.com/wiki/Highlight_text_beyond_80_columns
Good stuff! I will be poking my nose in there later.
> Is there a way to draw people's attention to tips like this
> in the Wiki, (i.e. ones where work has been done and further
> comments are sought)?
In theory, people would notice "Recent changes" (a link in the sidebar when you
visit any vim.wikia.com page), and they would notice that someone had edited a tip,
then would check what you had done. If you leave a comment (like you have in this
tip), a keen reader would notice and respond (Fritzophrenic has done that, and it's
on my todo list). Notice that the history tab has a good diff view, so readers can
see what changes have occurred.
In practice, not enough people patrol the wiki.
We have a {{Todo}} template, but that just leaves a note for future archaeologists.
See:
http://vim.wikia.com/wiki/Category:Todo
I think the best thing to attract attention is to shout here, as you are doing.
> Perhaps a way to make a tip, whether a new one or a
> tidied old one, a 'New tip' candidate is what I'm seeking, so
> they go through the normal review, etc. and then get given a
> permanent ID.
>
> Speaking of which...how does that work? A lot of tips that
> already have IDs are rubbish. Do they still get to keep their
> IDs? Perhaps we should be, after reviewing tips, giving them
> IDs in a new namespace with the eventual aim of removing the
> old tip IDs completely?
The 'New tip' procedure is handled by me and some scripts that I run. For example,
fairly soon I will decide that the May new tips have had enough consideration, and
will manually assign tip ids to those tips we are keeping, and will attend to the
others (adding {{Delete|reason}} to proposed tips we are not keeping).
Re the old tips: It really is true that "a lot of tips ... are rubbish". We (slowly)
handle that with these steps:
1. Copy any useful info from a bad tip somewhere else (sometimes I just add it as a
comment in a relevant tip, to be merged later).
2. When all such useful info (if any) has been copied elsewhere, add one of these
templates at the very top of the tip:
{{Merged|123}}
{{Delete|Brief reason why tip should be deleted.}}
The first is preferred. Replace the "123" with the number of the most relevant tip
where the info has been copied. Sometimes NO info has in fact been copied (because
there wasn't any), but we still put a relevant tip number to direct readers to a
useful place.
Both Merged and Delete will flag a tip to be deleted. See:
http://vim.wikia.com/wiki/Category:Candidates_for_deletion
After any discussion, the tip will be deleted (by me). If, for example, tip 5 is
deleted, I also update the VimTip5 page that provides previous/next navigation. Bram
still has the old tips at vim.org, and each tip has a link to the wiki. For example,
on vim.org, tip 5 links to:
http://vim.wikia.com/wiki/VimTip5
If you visit the above page, you see this message:
Tip 5 has been removed
...
The original tip was at Tip#5. (link to vim.org)
Tip 5 has been merged to VimTip1 (link to merged tip)
Because of the above, I don't think we'll be implementing a new namespace any time
soon.
However, I would encourage people to BE BRUTAL and help delete unhelpful tips. Care
is needed because sometimes a 100-line confused tip will have a 2-line pearl of
wisdom on something totally unrelated. We should move that pearl somewhere before
flagging the tip for deletion.
IMHO having too many tips is not helpful for readers, and is really destructive for
editors because there is just too much work to do. We have had a few people argue
that most tips should be retained ("it will be useful for someone"). Most of those
people, however, don't have time to fix the tips, so we stay in the current messy
situation where not many tips are actually good for current Vim.
John
Tony Mechelynck
* The way I see it (the vim-wiki admin may disagree, and, until or
unless this wiki gets a "democratic" structure similar to the
Wikipedia's, he has the last say), the "tip number" is just a crutch, a
leftover from the vim.sf.net tips: here you can give your tips a name to
describe them. It's the _title_ which is the tip ID. IIUC, the Main Page
includes (or, if it doesn't it should) a "New Tips" (or "New articles")
section anyway.
* How to have people find your tip when they want it? Have you worked at
the Wikipedia? The principle is the same:
- Try to think of the most general title which would describe your tip
- If some other title would describe it equally well, create a redirect
page so both titles find the same text.
- If the tip was formerly known by a less general or less adequate
title, create a redirect for the benefit of anyone who might have
bookmarked your tip under its former URL, and of any other tip which
might have a link to it in its text.
For instance, let's imagine that you decide that "Highlight a
user-defined right margin" would be a more general title. Use "move this
page" in your tip's toolbar to move it there. Then check that, at your
former title, there is now a redirect page, and if there isn't, create
one so clicking in your post above will still find the text where it is.
Maybe also make a redirect page at "Highlight text beyond a certain
column" pointing to the same page. The redirect page(s) would simply
contain (after the move) the following wikitext (one line):
#REDIRECT [[Highlight a user-defined right margin]]
which you could display by "editing" the page (the redirecting page, not
the one redirected to). Simple, isn't it? Almost Vim-like ;-). The
[[VimTip810]] redirect should also point to the final page, not to an
intermediary redirect. If necessary, browse to it, then select its name
under the title of the "redirected" page to get the "redirecting" page
without being redirected, and there you can edit it.
* How to make tips stand out when in need of reworking? There is at
least one template for that: if you include {{review}} (with the braces)
near the top of your text, it will produce a box like the big pink one
near the top of
http://vim.wikia.com/wiki/Use_gvim_as_an_external_editor_for_Linux_apps
. Similarly, the Wikipedia has the {{stub}} template for small
placeholder articles which need to be expanded. I don't know if the
vim.wikia has it.
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
97. Your mother tells you to remember something, and you look for
a File/Save command.
Tony Mechelynck
> Matt Wozniski wrote:
>> On Tue, Aug 5, 2008 at 12:32 AM, Ben Schmidt wrote:
>>> Is there a way to draw people's attention to tips like this in the Wiki, (i.e.
>>> ones where work has been done and further comments are sought)? Perhaps a way to
>>> make a tip, whether a new one or a tidied old one, a 'New tip' candidate is what
>>> I'm seeking, so they go through the normal review, etc. and then get given a
>>> permanent ID.
>>>
>>> Speaking of which...how does that work? A lot of tips that already have IDs are
>>> rubbish. Do they still get to keep their IDs? Perhaps we should be, after
>>> reviewing tips, giving them IDs in a new namespace with the eventual aim of
>>> removing the old tip IDs completely?
>> I definitely think that we should get rid of the tip ID system
>> entirely. It just doesn't make any sense on a wiki. In fact, I'd
>> argue that we should do away with it ASAP, and every time we can agree
>> on the title for an old VimTip we should create the article at that
>> title and keep the VimTip### entry only as a redirect to the Tip Title
>> one...
>>
>> ~Matt
>
> Sounds good. Only one concern: there should be a way to link to a tip by
> URL with confidence that it won't change. So we need to have some policy
> of "once a title is agreed upon, it can't be changed" (or only rarely
> and with a redirect in place) or something like that.
>
> Ben.
>
if only because some people may have bookmarked that redirect; but
people should notice that it is a redirect, and *at least* mention the
English title (which is more descriptive) when mentioning some tip in
this ML.
But for new tips, I don't see why a "tip number" would be necessary or
even useful.
Best regards,
Tony.
--
Machines certainly can solve problems, store information, correlate,
and play games -- but not with pleasure.
-- Leo Rosten
John Beckett
Yes, but these issues can be sorted out when at least (say) 50% of the tips have
been fixed (or deleted).
It's true that I am in the habit of posting links to VimTip123 -- that's because I
have a system that makes it easy for me to do that (e.g. I have a copy of each tip
in a file, and tip 123 is in file 0123.wik). I'll improve one day.
John
John Beckett
> I definitely think that we should get rid of the tip ID
> system entirely. It just doesn't make any sense on a wiki.
> In fact, I'd argue that we should do away with it ASAP, and
> every time we can agree on the title for an old VimTip we
> should create the article at that title and keep the
> VimTip### entry only as a redirect to the Tip Title one...
I can see the logic to that, and it certainly is true that the current situation is
contrary to the way a wiki should work.
The main reason I'm going to the trouble of maintaining the tip numbers is so the
old tips which Bram still has on vim.org don't have broken links. For example, see
this old tip:
http://www.vim.org/tips/tip.php?tip_id=667
On that page, it says: "Read and edit this tip on the Vim tip wiki". That phrase is
a link to the current, greatly improved tip:
http://vim.wikia.com/wiki/VimTip667
Also, I think there is some value in providing an explanation for what's happened.
Many people have contributed to the old tips, and they may browse their work
occasionally. For example, this old tip:
http://www.vim.org/tips/tip.php?tip_id=200
has a link to the wiki, and on the wiki, tip 200 says that it has been merged to tip
6 (with a link).
Also, for those of us working on the wiki (hi Fritzophrenic!), it is quite handy to
have a way to quickly refer to tips that need to be merged. For examples, see:
http://vim.wikia.com/wiki/Category:Duplicate
We could achieve your suggestion by editing the Tip template so it doesn't show the
tip number, and doesn't show the previous/next navigation. That would instantly
remove the tip number from each tip. That can be done at some stage, but I find the
tip numbers quite useful for a quick reference (and my maintenance scripts use
them).
The big question is what to do with the old tips (e.g. those listed at
Category:Duplicate). The tip number issue is simple by comparison.
A final point: We have left the issue of assigning categories to each tip to be
resolved one day. We need some careful thought on how to arrange the categories.
Once that's done, I can assign categories relatively painlessly with scripts, but
deciding what categories to use is very difficult. A lot of Wikipedia works by
categories, and the countless editors who maintain them. Until we have useful
categories, I quite like the previous/next navigation. That works on tip numbers (it
would be too hard to maintain without them).
John
John Beckett
> But for new tips, I don't see why a "tip number" would be
> necessary or even useful.
There is no necessity for a tip number for new tips. However, it is only a small
overhead to include it, and I'm happy to do it.
I decided that a number for each new tip was worthwhile so there would be a better
compatibility between old and new tips, but mainly to be an excuse to have a
"proposed new tips" procedure. Currently, a new tip has to be considered, and we
have to choose to assign it an id. Until that time, there is a slightly jarring
"proposed new tip" template that alerts readers (and the author) that the tip is
new, and has not yet been "accepted" by the community. Roughly a third of proposed
new tips have been deleted, after useful content was copied to an existing tip. The
"need" to assign a tip number motivates editors to get the job done, rather than
letting proposed new tips get lost in the pile of old stuff. Unlike Wikipedia, we
have no eager band of "deletionists" who are happy to confront an author and
brusquely state that a new article should be deleted. We have a positive way of
approaching this, where we ask, "Should this proposed new tip be given an id?".
Reminder to everyone: We welcome opinions on the new tips! See the "New tips" link
in the top-left box on the main page (vim.wikia.com). That link is:
http://vim.wikia.com/wiki/Vim_Tips_Wiki:New_tips
Re the "better compatibility between old and new tips": After pondering how to
handle new tips, I decided it was simpler to give each new tip an id (tip number).
Then, we wouldn't have to explain to people that some tips had an id, and some
didn't. Also, tip navigation (previous/next) uses the id, and again I didn't want to
explain why that worked on some tips but not others (and I definitely did not want
the overhead of maintaining previous/next links to somewhat ephemeral tip titles).
Also, we have a couple of maintenance templates (mainly "Duplicate" to flag tips
that need to be merged). It's easy to put {{Duplicate|123|678}} in a tip to indicate
that its content duplicates what is in tips 123 and 678. Using the correct titles,
and maintaining them, would be a burden (and we sometimes need to flag new tips as
duplicates).
John
Benjamin Fritz
John has said most of what I would say about the tip numbers, so I'll
try not to repeat him too much. In short, the wiki references tips
with _both_ a descriptive name _and_ a number.
http://vim.wikia.com/wiki/VimTip1 will get you to the same place as
http://vim.wikia.com/wiki/The_super_star so I really don't see what
the problem is. When searching or browsing for a tip on a particular
topic, I will certainly use the english title. But it is nice to have
the alternate method of referring to tips for brevity and ease of use
for quick notes. It can be difficult, especially for tips that do not
necessarily abide by our title guidelines (
http://vim.wikia.com/wiki/Vim_Tips_Wiki:Title_guidelines ), to easily
remember a tip title when making notes to other people, etc. (granted,
I can just load the tip in a new page/tab and copy the URL). Also,
there's the question of tradition. Not the best reason, but Vim Tips
have _always_ had a tip ID...why get rid of them?
As for calling attention to major changes, the best bet is probably to
use either this list or the wiki mailing list, rather than using
{{review}} or the recent changes page. Although either of the latter
methods should _in_theory_ work fine, there are not yet enough active
editors on the Vim Tips wiki to just notice the change and do
something about it, and the {{review}} template is alreay in place on
almost 1000 pages (mostly old tips imported from vim.org that have not
yet been cleaned up/updated for a more recent version of Vim). So,
adding {{review}} would hardly make a tip stand out. Once all the old
tips are cleaned up (or deleted, depending on the tip) the {{review}}
template will probably be helpful again, but in the meantime mailing
lists are the way to go.
Gene Kwiecinski
by
>URL with confidence that it won't change. So we need to have some
policy
>of "once a title is agreed upon, it can't be changed" (or only rarely
>and with a redirect in place) or something like that.
Can hash the text to generate a random-looking string, a la
tinyurl/snipurl.
Eg, "How to use vim to edit files!" --> 8C5F203A.
Tony Mechelynck
[...]
> As for calling attention to major changes, the best bet is probably to
> use either this list or the wiki mailing list, rather than using
> {{review}} or the recent changes page. Although either of the latter
> methods should _in_theory_ work fine, there are not yet enough active
> editors on the Vim Tips wiki to just notice the change and do
> something about it, and the {{review}} template is alreay in place on
> almost 1000 pages (mostly old tips imported from vim.org that have not
> yet been cleaned up/updated for a more recent version of Vim). So,
> adding {{review}} would hardly make a tip stand out. Once all the old
> tips are cleaned up (or deleted, depending on the tip) the {{review}}
> template will probably be helpful again, but in the meantime mailing
> lists are the way to go.
I think Vim Tip users should be encourage to watch the [[Main Page]]
and/or the [[Vim Tips Wiki:New tips]] page (the latter is linked from
the former); and I mean watch, not just bookmark: with a watch you'll be
warned of any changes (by email if you enable that in your Preferences,
and by a line at the top of any page you view in any case).
Best regards,
Tony.
--
XIIdigitation, n.:
The practice of trying to determine the year a movie was made
by deciphering the Roman numerals at the end of the credits.
-- Rich Hall, "Sniglets"
John Beckett
> Can hash the text to generate a random-looking string, a la
> tinyurl/snipurl.
>
> Eg, "How to use vim to edit files!" --> 8C5F203A.
Yes, but there currently is no mechanism to hash a tip title to produce a short URL.
OTOH we have the tip number mechanism working with no problems.
When someone asks a question here, I might recall that there is a tip with some
useful info. Because of my personal system, I can quickly find the tip number and
post its URL in a message here. Apparently that has irritated people who would like
to see the tip title.
Apart from that issue, is there any problem with tips having numbers?
A few more opinions on the proposed new tips for May, June and July would be good:
http://vim.wikia.com/wiki/Vim_Tips_Wiki:New_tips
And there are lots of helpful things to do on the wiki:
http://vim.wikia.com/wiki/Vim_Tips_Wiki:Todo
John
Matt Wozniski
> When someone asks a question here, I might recall that there is a tip with some
> useful info. Because of my personal system, I can quickly find the tip number and
> post its URL in a message here. Apparently that has irritated people who would like
> to see the tip title.
>
> Apart from that issue, is there any problem with tips having numbers?
Not really - I forgot that tips can be referred to by the full title,
too, and that removes what I thought was the obnoxious thing about tip
numbers. I wish that the address bar showed, eg,
http://vim.wikia.com/wiki/The_super_star when I followed a link to
http://vim.wikia.com/wiki/VimTip1 - but that might be asking too much.
I also wish the server weren't case-sensitive, eg. that
http://vim.wikia.com/wiki/The_Super_Star worked... that might be a
little more attainable?
~Matt
Tony Mechelynck
Well, for individual tips it can be done by adding a redirect. If you
want it for all of them you'd have to program a bot to do it.
Best regards,
Tony.
--
Iron Law of Distribution:
Them that has, gets.
John Beckett
> I also wish the server weren't case-sensitive, eg. that
> http://vim.wikia.com/wiki/The_Super_Star worked... that
> might be a little more attainable?
In principle we could do what Tony suggested, and make lots of redirects. To spell
it out, you would create a new page called "The Super Star" and you would put a
single line on that page:
#REDIRECT [[The super star]]
I would urge people to NOT do this at the moment. Lots of tips still have dodgy
names. What we should do is get all the titles in reasonable shape BEFORE creating a
bunch of confusing redirects. However, I don't think we are even ready to rename the
tips -- I would far prefer people helped by cleaning up the tips we have (often by
deleting old stuff, as I recently mentioned). When most tips are ok, we can spend
time wondering about titles.
The best way to find tips would be to have the categories in good condition. For
example, to find tips on searching you would use the "Browse...by category" box on
the main page: Click the "+" next to "Usage", then click the "Searching" category.
That works quite well for "Searching" because it is easy to know what category a tip
on searching should be in. A lot more work is needed for other categories.
I have wondered whether it would be worth making a page holding all 1210 tip titles.
You could search that pretty rapidly for a partly-remembered name, or perhaps just
browse it. You can see all tips using the "Special pages" link in the side bar, but
a single list would be easier. To get an idea of how that would look, you could
browse
http://vim.wikia.com/wiki/User:JohnBeckett/Titles_that_do_not_need_to_be_changed
which is a record of 651 titles that we did not change in October 2007 (when we
renamed 578 other tips).
John
John Beckett
>> Apart from that issue, is there any problem with
>> tips having numbers?
>
> Not really - I forgot that tips can be referred to by the
> full title, too, and that removes what I thought was the
> obnoxious thing about tip numbers. I wish that the address
> bar showed, eg, http://vim.wikia.com/wiki/The_super_star when
> I followed a link to
> http://vim.wikia.com/wiki/VimTip1
If you use "VimTip1" to visit a tip, that is what you will see in the URL. I don't
think there is any way to change that. In particular, if you click the "Previous
Tip" or "Next Tip" links you will see a VimTipNumber URL.
I just changed the template to make it easy for anyone inclined to obtain the
"proper" URL for a tip. For example, if you visit
http://vim.wikia.com/wiki/VimTip2
You will see:
Tip 2 . Previous Tip . Next Tip
"Previous Tip" links to VimTip1, and "Next Tip" links to VimTip3.
What's different is that "Tip 2" links to the "proper" URL:
http://vim.wikia.com/wiki/Easy_edit_of_files_in_the_same_directory
If anyone wants to try this out, you will need to know that the wiki holds the html
for each page in a cache. That cache was NOT flushed when I edited the template.
Therefore, you may easily see how the page appeared BEFORE my edit. Following is how
to overcome that problem.
If you visit http://vim.wikia.com/wiki/VimTip9 you will see "(Redirected from
VimTip9)" just under the page title, at the top. Click "VimTip9" to go to the
redirect page. Then click the redirect (which is the title of tip 9). This returns
you to tip 9, but you now see the full URL (not "VimTip9").
In the address bar of your browser, append "?action=purge" (no quotes) to the URL,
then press Enter. You should now see what I described above for VimTip2. I believe
the wiki will eventually purge its cache and people won't need this trick.
Having the "proper" URL in a link is a pretty trivial improvement, but it might be
helpful sometimes.
John
Ben Schmidt
> condition. For example, to find tips on searching you would use the
> "Browse...by category" box on the main page: Click the "+" next to
> "Usage", then click the "Searching" category. That works quite well
> for "Searching" because it is easy to know what category a tip on
> searching should be in. A lot more work is needed for other
> categories.
I agree that a categorised catalogue of tips would be the best way to
organise them.
Could the interface of the categories be improved, though? I find it
pretty hard/annoying to use, so I don't much.
For instance, it's annoying to push the [+] link just to see 'no
subcategories.' It would be heaps better not to show the [+] at all.
Also, it's annoying that tips can be placed in categories as well as
subcategories. For instance, if I'm interested in mapping, I can look in
Usage->Mapping. But the tip might not be there, because it might just be
in Usage. To my mind, it would be heaps better if tips were all at
leaves in the category tree, not at all nodes, even if that means a few
leaf nodes called 'Other' need to be added. Then the category system
would be heaps easier to use, too: you wouldn't need the [+] links at all,
you could just click the titles (which are bigger and thus much easier
to hit, too); if you clicked a title with no subcategories, it would be
a leaf so would redirect your browser to the appropriate page listing
tips; it if had subcategories they would be displayed just like pushing
the [+] currently does.
> I have wondered whether it would be worth making a page holding all
> 1210 tip titles.
Yes, I think it would; I was going to ask for this. Particularly if for
contributors (or perhaps make a separate page) it could also contain the
'status' of each tip: i.e. 'proposed new tip', 'newly created tip',
'imported tip', 'accepted tip', or whatever else is helpful. Then we'd
have a vague chance of knowing where we were up to which is something I
struggle with: I don't even know how to find these 100s of untidied tips
that need work, so I do no work on them. I also don't know a reliable
way of finding candidate tips to merge with. If there was a nice
list--much like a bug tracker (which is another thing I was pretty much
going to ask for...) then I could just pick a tip every now and then and
work on it. Contributers also need a way to change the status from
'imported tip' or 'newly created tip' into 'proposed new tip' which
signals that it has been tidied and needs review. Then after comments
have been made John can give it an ID and change it to 'accepted tip.'
Another reason I was wanting to suggest a bug tracker is to be able to
assign responsibility. I didn't know about the watch function, but
thanks to Tony for pointing it out! That will help a lot when seeking
comments, to be able to get emails when people actually do comment. I'll
have to figure out a convenient way to use it, but at least I know it's
there now. However, it's all a bit vague at this stage, and I think this
is often the case: I tidied up the tip and asked for comments. But who's
responsible to finish the tidying in response to the comments? Is
anyone? Or does John just end up having to do it when it becomes a
proposed new tip? If all the work other contributors do just ends up
making more work for John, the speed of fixing this stuff is not going
to increase! I'd be happy to finish fixing that tip, but I need some way
for it to be assigned to me, or to at least signal in the tip that I
intend to do so, and probably when (e.g. after a one month comment
period or something). Ideally I could signal this with some template and
get an automatically emailed reminder at the end of the comment period
so I'd go back, review the tip, adjust it in response to the comments,
and leave it nice and tidy for John to just approve as a new tip.
I would also find it easier if the proposed new tips were not separated
by month, and if the comments on these were local to those tips. Are you
sure it's not a good idea to use the talk pages? I would think this
would make things so much easier and it also makes the wiki look like
a useful resource rather than a work in progress with comments all over
it. I would find it much easier if there was just a page for 'tips
needing tidying' (all 'imported tips') and a page for 'tips needing review'
(all 'newly created tips' and 'proposed new tips'), preferably sorted by
date of when the review period is due to end if such a thing is taken on
board. Then I don't have to figure out which months of tips to look at
(I mean, are we up to May or June or April at the moment or what?! It's
AUGUST folks! How many months back am I supposed to look? And am I
supposed to look at August yet?)
It would also be good if there was a single, fairly short, or at least
terse, 'how to contribute' page that simply lists the core development
procedures, without getting too bogged down in bureaucratic nonsense
like 'policies.' E.g. To help with tidying: go to page
Tips_needing_tidying and pick one; when you tidy it remove the
{{Needs_Tidying}} template and instead place the {{Needs_Review}}
template on it; Indicate you intend to review comments at a particular
time using the {{Assigned_To|username|01Jan2020}} template; return to
adjust your tip on the specified day; leave the date in the past to
signal to John that the tip is ready for an ID, or set another future
date if further review is needed. To help with review: go to the page
Tips_needing_review, visit the tips, add comments on their talk pages.
To help with categorisation: visit tips and add to categories using the
{{Category}} template. When editing tips: to get vimscript to appear
properly, put inside <pre></pre> tags; when you reference vimrc, do it
like [[vimrc]]; when you reference help..., etc. At the moment the help
with this is just on too many pages, with the relevant mixed with the
less relevant, and the user stuff mixed with the contributor stuff. I've
read a good number of pages on this stuff and still have barely any
clue, and it's been a few months since I've begun to be involved. I
mean...I guess what I'd like is a nice page about contributing that's
like a Vim tip!--not too much detail, only relevant stuff, easy to find.
Anyway, that's a bunch of ideas about how I think the wiki could be
improved, particularly from the point of view of a potential, and
probably quite keen, contributor, but also as a user, since I contribute
so little due to these issues that I really am more of a user at
present. Overall, although I find the wiki heaps better than the vim.org
tips database thing, I still find it pretty frustrating.
That's certainly not to say that the work that is being done on the wiki
isn't absolutely fantastic. It is already a formidable resource and the
work done so far, particularly by John, is amazing.
Ben.
Tony Mechelynck
> Matt Wozniski
>> I also wish the server weren't case-sensitive, eg. that
>> http://vim.wikia.com/wiki/The_Super_Star worked... that
>> might be a little more attainable?
>
> In principle we could do what Tony suggested, and make lots of redirects. To spell
> it out, you would create a new page called "The Super Star" and you would put a
> single line on that page:
>
> #REDIRECT [[The super star]]
>
> I would urge people to NOT do this at the moment. Lots of tips still have dodgy
> names. What we should do is get all the titles in reasonable shape BEFORE creating a
> bunch of confusing redirects. However, I don't think we are even ready to rename the
> tips -- I would far prefer people helped by cleaning up the tips we have (often by
> deleting old stuff, as I recently mentioned). When most tips are ok, we can spend
> time wondering about titles.
>
> The best way to find tips would be to have the categories in good condition. For
> example, to find tips on searching you would use the "Browse...by category" box on
> the main page: Click the "+" next to "Usage", then click the "Searching" category.
> That works quite well for "Searching" because it is easy to know what category a tip
> on searching should be in. A lot more work is needed for other categories.
I agree that creating "confusing redirects" must wait until "the title
is in reasonable shape" -- for each concerned article. But the idea with
a wiki is not that you first set up all the categories, then rewrite all
the articles' style, then rewrite all the articles' titles, then create
all the redirects, and so on. Done like that, you'll never get to step 2
because new articles are added all the time. Everything must run in
parallel: rewriting the text and rewriting the title don't depend on
each other, they can be done in any sequence. As soon as we agree that
some article's title is "all right", redirects can be added to it (and
in some case even earlier than that, if the wording is independent). All
the while, categories can be defined and articles added to them. When I
was working with an EDP servicebureau, we ran (for some of our
customers) a program named PERT which would optimize a set of jobs by
determining which jobs (as many as possible) could be done in parallel,
which ones had some slack in their schedules (and how much) and which
ones didn't. Here, what I'm outlining for the wiki may frighten some
people by its "anarchic", "untidy", "disorganized" way of doing it, but
here (a healthy dose of) anarchy is a virtue: its puts the various small
tasks to be done into a network rather than a linear sequence, thus
allowing more of them to run together, which in turn allows the whole
project to proceed -- like a crowd of traveling ants rather than a
battalion of soldiers all walking to the same pace.
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
101. U can read htis w/o ny porblm and cant figur eout Y its evn listd.
John Beckett
Go for it! I'm sorry if I've given the impression that you should NOT rename pages
and add redirects.
What I mean is that my preference would be for people to look for tips to clean up
(merge or delete), rather than LOOK for titles to fix. If, after editing a tip, you
decide that the tip should have another name, and possibly a redirect, please make
the change. It would be best if editors first read the "title guidelines", and spend
some time getting a feeling for how other tips are named so changes are consistent
with the wiki. However, there is no extra pay for doing that!
The wiki needs some urgent attention to avoid good tips being lost in the pile of
confusing old stuff. On my more radical days, I think that half the tips should be
deleted. Therefore, when a discussion on changing titles comes up, I'm going to say
that IMHO titles aren't really important (but bear in mind that I arranged for 578
bad titles to be renamed last year, so I'm not saying that titles are unimportant).
John
John Beckett
> I agree that a categorised catalogue of tips would be the
> best way to organise them.
>
> Could the interface of the categories be improved, though? I
> find it pretty hard/annoying to use, so I don't much.
I've just asked on the Wikia mailing list whether anything can be done re the
annoying "[+]" which you have to click to be told "no subcategories". I'm going to
think about your other comments and may respond later. The quick story is that the
categories are a bit of a mess, mainly because it's hard working out what categories
should exist, and then checking to see if (say) 80% of the tips would fit the plan.
I have wondered whether it would help to use some of ":help toc" as a basis for
categories.
>> I have wondered whether it would be worth making a page
>> holding all 1210 tip titles.
>
> Yes, I think it would; I was going to ask for this.
OK, I'll do something and announce soon. I'll think about your suggestion to add a
'status', but I'm not sure what can be achieved. I'm inclined to just show the tip
number (and title). Numbers over 1504 are "new" (added since July 2007 and not on
vim.org). Numbers under 800 are pretty old and probably need brutal love.
I can certainly flag those tips that have the {{review}} template, but that would be
redundant because Category:Review lists them. To see this, visit any page, then
click "Categories" in the side bar. I should mention that I log on and have
"MonoBook" selected under Skin in "my preferences". For me, "Categories" is on the
left and is easy to see. The default skin is rather more confusing IMHO (we can't
set MonoBook as the default).
You now see the "Category:Browse" page. Click the + next to "Administration of this
site". You will see various maintenance subcategories, including "Duplicate" and
"Review". Time spent in Category:Duplicate would probably be the most rewarding. We
try to merge tips towards the smaller number. If you see that tips 100, 150 and 180
are duplicates, you might copy any useful info from 150 and 180 to 100. We would
later delete 150 and 180, and finish cleaning of 100. See
http://vim.wikia.com/wiki/Vim_Tips_Wiki:Merge_guidelines
> Another reason I was wanting to suggest a bug tracker is to
> be able to assign responsibility.
We don't really have enough activity at this stage to justify that level of
organisation. You can always use the "history" tab on a tip to see who has done
what, and when.
Re VimTip810 that you are working on (I will add my comments in a day or two): My
opinion is that the best thing is what you've done. Put a comment on the tip page
about what you plan to do (a very brief outline). Anyone who cares will use "Recent
changes" and notice what you've done. Certainly Fritzophrenic and I will notice, and
will comment if we have anything to say.
Remember that the wiki holds a complete history, so if you go crazy and delete a
bunch of stuff that you don't like, someone else can copy it from the old version
and paste it back. So we don't have to get agreement in advance.
I'll respond in another post to more of your points.
John
John Beckett
> Ideally I could signal this with some template and get an
> automatically emailed reminder at the end of the comment
> period so I'd go back, review the tip, adjust it in response
> to the comments, and leave it nice and tidy for John to just
> approve as a new tip.
Wikipedia can afford this sort of organisation (although they don't have such a
template), but we have a majority of pages which need extensive work, and only a
small number of routine workers. If you like, I'll email you each month, but I
wouldn't bother with anything more sophisticated!
> I would also find it easier if the proposed new tips were not
> separated by month, and if the comments on these were local
> to those tips.
The idea of separating new tips by month is:
- Make a smaller, more comprehensible list.
- Make it easier to say "all done" and have someone (me) promote the tips by
assigning an id.
- Focus attention on stuff that should have been resolved (e.g. May new tips still
not fully resolved in August).
It's good to keep discussions in the same order so the history works. If there was
one big list of new tips, then we would have to remove discussion on a tip when it
was finalised. That makes the differences shown by history very hard to follow
(useless).
> Are you sure it's not a good idea to use the
> talk pages? I would think this would make things so much
> easier and it also makes the wiki look like a useful resource
> rather than a work in progress with comments all over it.
Yes I am certain! However, by all means experiment. Pick a tip (say the one you are
currently looking at) and move the comments to the talk page. Then we can reply on
the talk page.
I think you will notice these problems:
- On each pass, you will have to edit two pages instead of just one.
- You will feel uneasy about deleting old comments on the talk page ("I can't delete
that stuff that John wrote, even though I've dealt with it"). The result will be a
very hard-to-follow mess. Instead of spending time fixing the tip, you will spend
time wondering about the talk page, and how to reply to my comments.
- Each of us will be the same.
- We will forever have a talk page and editors will repeatedly check it out,
spending time trying to decode obsolete conversations (time which would be better
spent elsewhere).
- A reader may find the tip and not notice the talk page. They might get totally
misled (a comment could say "a much better way to do this is ...").
I find that discussions on the tip page get to the point much more efficiently.
Fritzophrenic and I have done this many times. We just delete the comment when it is
dealt with. Another editor can always use history to see the old comments if really
concerned.
It is true that in the case of your tip that you and Fritzophrenic have been very
verbose, and a talk page might be warranted. But as soon as I get around to it, I'm
going to refactor the whole thing!
> would find it much easier if there was just a page for 'tips
> needing tidying' (all 'imported tips') and a page for 'tips
> needing review' (all 'newly created tips' and 'proposed new
> tips'), preferably sorted by date...
The wiki way is to use categories (unlike the Vim categories, the maintenance
categories work). As mentioned in my other message, browse "Categories" in the side
bar, and expand "Administration of this site". The various categories do what you
want. For "newly created tips", you need Category:VimTipProposed (not under
"Administration of this site"). This is not as good as you would like, but it will
give you lots to do!
If you want an overview of everything, perhaps I should make a zip of the wikitext
of all tips. You can quickly search local files to get an overview, but there really
is enough to do simply in Category:Duplicate.
> Then I don't have to figure out which months of tips to look
> at (I mean, are we up to May or June or April at the moment or
> what?! It's AUGUST folks! How many months back am I supposed
> to look? And am I supposed to look at August yet?)
If you look at April, you can see that it says that it has been completed, and you
shouldn't touch that page (it is an archive).
The August page says that it should not be touched until the end of August (because
a script I run generates the page).
We are late handling May because it contains the somewhat controversial
recommendation to delete the three tips that rely on external web sites. I would
still appreciate any comments on that point, but I will finalise it within a few
days. June is nearly decided. July is only a week old, and awaits attention.
The message you see on proposed new tips suggests that discussion should ONLY occur
on the "new tips" page. I should improve that wording. What I mean is that
discussion about whether a proposed tip should be kept or deleted or merged should
be on the new tips page (usually). If you have some specific comments on the
substance of a new tip (more than a couple of lines), please add them to the bottom
of the tip (obviously, only if you think the tip should be kept).
> It would also be good if there was a single, fairly short, or
> at least terse, 'how to contribute' page that simply lists
> the core development procedures, without getting too bogged
> down in bureaucratic nonsense like 'policies.'
OK. I'll look at your suggestions. Thanks. If necessary, prod me later!
John
John Beckett
> For instance, it's annoying to push the [+] link just to see
> 'no subcategories.' It would be heaps better not to show the
> [+] at all.
I got a reply from the Wikia mailing list:
"The new version of CT for MediaWiki 1.13 will show [x] instead of [+]
for empty categories. It can also show the number of subcategories,
pages and images on each category entry. This is based on additional
information in the database that has become available since 1.13."
I was told that the new version may be available in a few weeks.
John
Richard Hartmann
> I would urge people to NOT do this at the moment. Lots of tips still have dodgy
> names. What we should do is get all the titles in reasonable shape BEFORE creating a
> bunch of confusing redirects.
I would argue that redirecting from the name to the number would make more
sense. Names and descriptions can change, but IDs will not.
That would also allow you to reference a single tip under several names in a
clean way.
We might need to ask the wikia people if they would be willing to add a feature
that allows mediawiki to show the redirecting, not the target page in window
title, though.
Richard
Tony Mechelynck
Well, I take the opposite standpoint; I'll develop it here, if only in
order to light the subject from a different side.
When I see
http://vim.wikia.com/wiki/Scroll_alternate_window
http://vim.wikia.com/wiki/Using_vim_to_view_source_and_edit_textarea_in_mozilla/firebird
http://vim.wikia.com/wiki/Remove_unwanted_empty_lines
in an email, it already gives me some idea of what these links are
about, and maybe even of which ones might be more "interesting" to me
than others; but when I see
http://vim.wikia.com/wiki/VimTip131
http://vim.wikia.com/wiki/VimTip581
http://vim.wikia.com/wiki/VimTip72
for the same three articles (yes, they _are_ the same), I don't get any
such info.
And if what you want is to just browse from one unknown tip to another,
with no particular problem in mind, then even if there were no numbers
(and thus no "Previous tip" "Next tip" links), you could just use the
"Random page" in your wiki sidebar; use it repeatedly and you'll get a
different tip every time (well, almost every time: if you keep at it
long enough, you might in theory get to a point where you'd have seen
all tips, or a majority of them, and you'd then start getting fewer and
fewer "new" ones).
Even if the title changes ("if an article is moved", in Wikimedia
language), the "old" title should in most cases not be deleted outright,
but remain as a redirect, if nothing else for the benefit of links (in
the wiki or even elsewhere) and bookmarks (in users' browsers) pointing
to the former title.
Best regards,
Tony.
--
"The Right Honorable Gentleman is indebted to his memory for his jests
and to his imagination for his facts."
-- Sheridan