Tags:
create new tag
, view all tags

Signature Netiquette

Signatures

The CodevCommunity is mainly operating in ThreadMode, which works well to discuss new features, brainstorm on ideas, and follow up on bugs. DocumentMode is also used where appropriate, like to finalize the spec of a new feature.

Topics in ThreadMode should be signed. Technically this would not be required because TWiki has a complete audit trail. However, to see quickly who has contributed what without the need to go to the diffs, it is recommended to sign and date contributions at the end of the text like:

-- TWikiGuest - 2017-04-06

Box is added for clarity; omit the box.

Please use a link signature pointing to your home page. The link makes it easy to spot the boundary between contributions. If you prefer an acronym, use the [[Main.UserName][ABC]] shorthand

Please avoid long signatures because this distracts from the main content, e.g. the signal-to-noise ratio suffers. Related, collaboration works best with a "get to the point" approach, that this, stick to the subject and link to related content.

-- PeterThoeny - 05 Aug 2003

Discussions

What's acceptable in a signature ?

Martin Cleaver is using an innovative signature that lets you see if he is currently online on YIM, which I think is kind of neat. This is accomplished with an %INCLUDE{}% of the user's home page, with the homepage having a %STARTINCLUDE{}% and %STOPINCLUDE{}% around the signature.

I find Martin's signature OK as long as it does not affect the signal-to-noise ratio. It makes it sometimes hard to see where the boundaries are between contributors. Initially he had it verbose; some folks asked to scale back, which he did. Then, on 01 Aug 2003 (the Swiss National Independence day BTW), he changed it to "MartinCleaver likes TWikiIRC, dislikes TWiki is suffering: PleaseEmpowerYourContributors".

-- PeterThoeny - 05 Aug 2003

Not only does it make reading topics harder, but I don't like seeing an INCLUDed signature used as a lobbying platform for whatever someone wants to bring attention to this week. It's raising oneself and ones opinion above the group and frankly I think it's having an adverse effect.

-- SamHasler - 04 Aug 2003

... Since I'm not on TWiki's CoreTeam (and nor do I wish to be - look at MartinCleaver's abusive signature for example) I cannot rectify these problems. ...

-- MichaelSparks - 04 Aug 2003

I copied Sam Hasler's comment from HowToDocumentPluginPerformance, and Michael Sparks' from TWikiOrgInBreachOfGPL.

I also find Martin's comment intrusive, and geared towards disturbing the teamwork of the CodevCommunity by spreading FUD (among facts) using PropagandaWithFearAppeal. Please read AppealToCodevCommunityByCoreTeam, addressing the teamwork question. I do not intend to start a flame war, which would just add noise to the signal. My intent is to make the CodevCommunity aware of what's going on and to be critical to those who try to disturb the teamwork. One of my favorite books on is and others subjects is: To Have or to Be, by Erich Fromm, ISBN:0826409121

How do other CodevCommunity members perceive Martin's comments?

-- PeterThoeny - 05 Aug 2003

First, I am very glad that Martin raises his voice: I think the main problem could be BewareOfTheQuietLeavers, so having people voice their opinion rather than just leaving the community is good. He raises valid concerns, IMHO. Where I disagree with him is that I do not think we (I mean people wanting TWiki to evolve) can agree on a common roadmap on the medium term, so I would be rather be in favor of quick, immediate small steps, to help people feel there is an evolving code base, instead of the current "out in the sky somewhere" devel version, and see if we can improve from there.

Basically, you can see Martin signature as a problem, but isn't it rather a symptom, whose cause if the frustration created by the feeling of decay TWiki development seems to have step into? In other words, better tackle the cause than the symptoms...

-- ColasNahaboo - 05 Aug 2003

Please see my signature as a tee-shirt, (hopefully) always relevant and reflecting the thoughts in my mind and the expression on my face.

I'll write more once my exams are over on Friday.

-- MartinCleaver - 05 Aug 2003

"always relevant"

Relevant to what? Certainly not the topics that it's included in. Why should one user be able to promote what they think is important across hundreds of unrelated topics? I'm not against included signatures per se just the way you've been using it although I think that if many people started using them it would be bad from a signal/noise perspective if not performance wise so I don't see why even one person should.

-- SamHasler - 05 Aug 2003

I agree with Sam - if "t-shirt" signatures could be limited to a few relevant topics, that would be fine, but they pop up everywhere. There's no offline equivalent, so t-shirt is probably a bad term, as this is basically spamming the same message into hundreds of web pages - looking like a spammer doesn't really convince people to listen to the message, to say the least...

-- RichardDonkin - 05 Aug 2003

Sorry Martin, I don't like the sig much either. Other people have already brought up the visual clutter and off-topic points so I won't do more than mention that I don't think it helps.

My other concern is about performance. If everybody, or even a significant portion of the community, starts using included sigs it will greatly impact the responsiveness twiki.org which already has significant performance issues.

-- MattWilkie - 05 Aug 2003

There seems to be consensus that a verbose signature just adds noise. Martin, could you remove your long signature. Probably a short version with the YIM status icon is fine.

-- PeterThoeny - 10 Aug 2003

Okay. So I've shortened it to address the visual concerns. I reject the performance issue as TWiki does a lot of file access anyway (e.g. for getting parents) and the underlying operating systems cache away repeated accesses.

-- MartinCleaver - 13 Aug 2003

I think the performance point is valid. Just because some parts of TWiki do extra file access, does not mean that signatures are an appropriate place for includes.

-- JohnTalintyre - 13 Aug 2003

I hate SPAM signatures ... I strongly vote against them.

Martin, the "standard" signature already links all your contribution to your home page.

If anybody wants to IRC you (or write you, or make love with you or wathever) you have plenty of space there to advertise youself.

Do we need a RemoveSpamSignaturesPlugin? smile .

-- AndreaSterbini - 29 Aug 2003

Smaller signatures

(section contents actually in subtopic SmallerSignatures)

The standard signature is nice but can make some pages not very legible for some ThreadMode pages for:

  1. long contributions: separation of paragraphs it is not clear: visually the signature do not seem to belong more to the previous paragraph than the next one
  2. very small contributions (one liners such as "me too", "I agree"...)
What could be the solutions? We may tolerate some other forms of signatures, but which ones?

closer to text have the signature with a preceding <br> like this:
-- ColasNahaboo - 16 Oct 2003

visually different render signatures in a different style, options:

  • specific tag: have users type things like:
    <div class=sig>-- ColasNahaboo - 16 Oct 2003</div>
    note that this could be just <sig>-- ColasNahaboo - 16 Oct 2003</sig>
    with the PseudoXmlPlugin
  • TWiki syntax: have the core recognize "\n[-][-] $mainWebname[.]" lines and expand them in the above
For, instance, with the CSS: .sig {text-align:right; margin-top: 0px; font-size: 85%; color: #555555;border-bottom:1px dashed #888888}
-- ColasNahaboo - 16 Oct 2003

all on one line (see also TerserSignature), possible forms:

Side note: The KoalaSkin (try it at http://koala.ilog.fr/wiki/bin/view/Test/WebHome) offers 3 triple-clickable cut-n-paste signatures: full, terse, and just the date (for people without JavaScriptDatePickerForForm)

-- Main.ColasNahaboo - 16 Oct 2003 <-- Ready to copy & paste signature
- [[Main.ColasNahaboo#16Oct103][CN]] <-- terser signature
16 Oct 2003 (triple click under most browsers)

Suggestions?

BTW, I realize that my TerserSignature patch is not in the core yet. Objections to its being "core-ified" ?

-- ColasNahaboo - 16 Oct 2003

Why don't we use the wikipedia method of using three tildes ~~~ or four tildes ~~~~ to insert just the name or name and date respectively on topic save. This way the sig could be inserted with whatever formating you want and if it changes in the future it isn't a surprise to the user. This decouples what the user has to insert or remember to type from any format or styling.

I really like this idea. It also has the added benefit of not caring whether the user home page is in a web called Main or Users or People or... If we extend the idea a bit more, each topic could have sig-mode metadata flag where mode is one of full, medium, terse, at-end, etc -- MattWilkie - 16 Oct 2003

-- SamHasler - 16 Oct 2003

Well, I like this idea too. Tildas are OK, or we could use a TWiki-style system (the --- prefix, so maybe ---~ for the terse one, which will not force a line break (span), and ---~~ for the long one, which will force a line break (div)?

-- ColasNahaboo - 16 Oct 2003

I don't see how that is any more TWiki than the wikipedia format, and besides I'm lazy smile and don't want to have to look for two keys (not counting shift for all the pedants out there) when one will do fine.

-- SamHasler - 17 Oct 2003

I'm with Sam on this one, dashes are for headings and section breaks. Using the number of tildes to determine the length (style) of the signature is a good ideas too.

-- MattWilkie - 17 Oct 2003

Another benefit of using PseudoXml to identify sigs would be that you could change the output format at a later date for all sigs without having to do a mass search and replace.

It would also allow different output on a per web/topic/user preference as Matt suggested above. So I could choose to see all signatures as long signatures while someone else could choose to see signatures collected at the bottom of a topic under a contributers heading, and someone else who has no preference see them as whatever the default for the topic is.

-- SamHasler - 20 Oct 2003

As a side note, this was not the original issue: what prompted me to create this topic is that I am used to use a shorter signature when I only contribe one line to the discussion, but on TWiki.org Peter re-edits my signatures to put them into the "policy-legal" form.

So in order to avoid this waste of time, I though it was time to see if we could have other forms of signature "legal" on twiki.org, it was a policy issue first rather than an implementation one smile

-- ColasNahaboo - 20 Oct 2003

Hmm, I haven't carefully read all of the above, but I thought I'd mention what I try / would like to do over on WikiLearn. Over there, I usually have a section at the bottom for contributors to the page. My intent is to:

  • beside the point: enter a contributor's name only once, for the first contribution (on that page) (after all, the details of his contributions are in the revision history)
  • include a brief comment marker (usually the contributor's initials) in parenthesis before the entry

In other words, something like this:

Contributors

Then I feel free to mark short contributions with my initials, something like — rhk, sometimes also including the date.

Since not that many people use the convention, duplication has not yet been a problem, but at some point we may need to avoid duplicates by, for example, appending a number (rhk001) or similar.

-- RandyKramer - 20 Oct 2003

Colas: Sorry if I took this off-topic, but I thought it would be easier to accept more than one signature format if it could be seen that there was a way of implementing it that was simpler than the current method. I think the implementation talk should be refactored out to a new topic perhaps SignatureShorthand.

-- SamHasler - 20 Oct 2003

To randy: this is not very different than my terse signature: - CN (just moving your pointer over it shows you the full name and date of comment)

To Sam: well, we can have both. I was just pointing out the original problem, but having nice ideas flowing is always welcome smile

-- ColasNahaboo - 21 Oct 2003

"just moving your pointer over it shows you the full name and date of comment"

It took me a while to work out you meant on the status bar. Better yet, add a title="ColasNahaboo -- 21 Oct 03" attribute to the anchor and have it on a tooltip SH.

-- SamHasler - 22 Oct 2003

Re: "To randy: this is not very different than my terse signature:"

Agreed! But it is less typing wink , and I was trying to address the policy issue by hinting that maybe the approach I adopted on WikiLearn could be considered as an alternate acceptable policy.

-- RandyKramer - 22 Oct 2003

  • To randy: it is no typing at all when it is offered as cut-n-paste in the skin like KoalaSkin does smile
  • To Sam: yes, but then your signature become a bit too big in edit mode...
-- ColasNahaboo - 27 Oct 2003

I was assuming it would be stored in some XML format like <sig date="28 Oct 2003">SamHasler</sig> and it would display in the shortened format I suggested, or any other format depending on web/topic/user preferences. Note that this conveniently doesn't specify which web the users home topic is in.

-- SamHasler - 28 Oct 2003


Building on some of the ideas expressed, I'd like to see a signed comment feature. Text enclosed by ~'s should be considered signed, rendered in a style defined by the user (variable on the user's page), and the appropriate (up for debate, maybe also a user preference?) signature added. Maybe have two options, terse and verbose signatures.

By having a markup for signing the entire whole comment, it becomes easier to filter the unsigned content out of a page (the DocumentMode stuff), which would be useful when collaborating on documentation. I've often wanted the ability to have a generate document button on a page which would filter out all of the discussion while leaving the content, and turn it into a pdf. But currently it's impossible to programmatically determine what is content and what it metacontent.

For example, the following wiki text:

~BTW, I like the tooltip example up above. This whole comment is tooltipped.~

~~But the signature should be verbose~~

would render as:

BTW, I like the tooltip example up above. This whole coment is tooltipped.

But the signature should be verbose. -- ScottGargash - 25 Nov 2003

Where the color, the italics and the form of the actual signature would all be set via user preferences.

edit SmallerSignatures

Encouraging DocumentMode

The rest of this topic largely talks about how a signature should look. At the top of the page, PeterThoeny suggests a signature style for thread mode topics. Encouraging document mode on some pages would be a good thing as well. (Cookbooks, summaries, etc)

One thought is this - how about a plugin that collects and removes all signatures and either a) places then in a contributors section at the end of the topic b) simply removes signatures and lists the Wiki names of all people who editted the page (as you can find from an rdiff of the page)? I note that pages that move signatures to the bottom of the page seem to operate better in document mode than thread mode - so making it toggleable on a page might be a useful thing. (It seemed to encourage a more document mode-like discussion in the VisionsOfTWiki topic after all)

ie How about providing a way to "enforce" document mode on some pages. Just a thought. (Could also have per user signature spam filtering wink )

Why So Many Sigs

Think about this question: why is it important to sign content with a signature? The information is all there in the diffs, as said at the top of this topic, yet look at the "list" of contributors below. If people really want to know, they can look. What people do want to know is what parts of the page are new. That's the primary purpose of the sig line, as I see it; to separate the old text from the newer text; without the date stamp, this would be quite a bit more difficult.

Thus, this is a usability issue dealing with the desire to see newness on topics, rather than who is responsible for a given paragraph. If I really cared who was writing what, I could look at the diffs. So TWiki should include markup for rendering newness something of that sort, and signatures would be less important altogether.

(no sig)

When I read a topic for the first time I often start at the bottom and work upwards until I have read enough to get the current state. I like being able to see the age of comments so I can tell if it has been idle for a long time and the comments at the end that are new are from people unrelated to the original burst of activity. I also like knowing who is contributing so I can see the distribution of different viewpoints and where there is consensus or if there are disagreements if they are from equally sized groups or a vocal minority.

If you want an automatic contributors section then it should probably be generated automatically from the diffs, not signatures. Also it's not clear it the date in the contributors section is the date of the first comment or the last for each person. Which do you think it is? Check if your assumption is correct, check more than one contributor.


Quandary: How does one emit a strong very good idea! to this alternate approach while keeping the discussion in document mode? :)

Contributors

-- PeterThoeny - 05 Aug 2003
-- ColasNahaboo - 05 Aug 2003
-- MartinCleaver - 05 Aug 2003
-- SamHasler - 05 Aug 2003
-- RichardDonkin - 05 Aug 2003
-- MattWilkie - 05 Aug, 16 Oct 2003
-- JohnTalintyre - 13 Aug 2003
-- AndreaSterbini - 29 Aug 2003
-- MichaelSparks - 29 Aug 2003

Edit | Attach | Watch | Print version | History: r18 < r17 < r16 < r15 < r14 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r18 - 2007-01-09 - RickMach
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.