Content

The Dot Contribute a Story page provides guidance on what we do and do not accept.

This is of course subject ot review, but it seems to be well observed so far. If an article is submitted that does not seem to match the criteria, we discuss it on list and then, if necessary, politely reject it.

Editorial Discretion

The above sets out the basic rules for what is suitable content for the Dot. however, the Dot is also seen as an official KDE News source, so we need to be careful about articles that may present issues in a particular way before the community has reached consensus.

The following categories of articles may need further attention and discussion:

New applications not using KDE infrastructure or the KDE Platform that claim to be KDE applications. These might include web applications or servers.
Any mentions of forks, splits, etc. Are there issues of legitimacy? Could the article prejudice ongoing discussions about the forking?

If any article or announcement troubles you at all on these counts, first raise it on the Dot Editors mailing list and then we can get guidance/consensus from some other experienced KDE marketing people/those involved in the announcement, if required.

Reviewing

Every article is reviewed by two editors prior to publication. Preferably neither of those editors was the original author. Reviews are requested on list with a link to the article and a statement on whether the article can be published straight after review or at some future date.

Reviews for urgent articles are sometimes also requested on IRC (editors may be found in #kde-promo or other kde channels). Also sending a message to the list notifying of iminent publication avoids someone publishing another article at the same time.

Scheduling

We try and avoid publishing multiple articles in one day (until or unless we get to the point of publishing on average more than one article per day). However, we don't hold very time sensitive article just for this reason.

Style

Interviews

Our current convention is to name both the interviewer and interviewee in an introduction at the start of the article, making their names bold with Name (you can also misuse for this or if you don't mind typing more and doing it 'properly' you could use Name - this would also allow us to use different colours for the names if we wanted...).

The questions and answers are then set out like:

Interviewer's name: Interviewer's question

Interviewee's name: Interviewee's answer

We obviously try and avoid heavy editing of the interviewees responses - imperfect English is fine, but should be corrected when it becomes hard to understand or ambiguous. We can also make changes to reflect the proper use of KDE brands (i.e. changing "KDE 4" to "KDE Platform 4" or "Plasma Desktop").

Language

We keep it kind of formal - so we tend to avoid using abbreviations: use "do not" rather than "don't" although that does not matter too much.

We can use jokes and a bit of jargon such as "hacker", but not emoticons (except in quotes or interview responses).

We try and edit in to good quality English as much as possible (but see the notes on interviews, above).

We use American English so it is "color" not "colour" and "ize" endings (some people argue that "ize" is also actually the correct ending in British English, but "ise" is more common). Luckily most non-native speakers seem to learn American English so it's the Brits (like me) that tend to screw this up.

Common English mistakes

These are some things that non-native (and native) English speakers often confuse and that you need to look out for when editing.

It's or Its

"it's" always means "it is". The possessive is "its".

So these are correct:

"KDE software is great, it's getting better all the time" (however, we would probably prefer "it is" here)

"KDE software is great, its biggest strength is consistency"

T or D endings in the past tense

A common error is "build" rather than "built" (and vice versa). The first in present or future: "he will build, I build, they build, he builds" while the latter is the past "he built it, I built it". I think there are some other ones that are similar, but I forget them at present.

Your and You're

"Your" indicates ownership: "it is your problem to correct the author's English"

"You're" means "you are" and generally we would prefer to use "you are".

Often non-native speakers use "your" when meaning "you're"

There, their and they're

"There" is used as in "there are", "over there", "while we were there".

"Their" indicates ownership "it is their problem to correct the author's English"

"They're" is the shortening of "they are", again we would probably prefer "they are".

Apostrophes for possession

Usually it is quite straightforward: if Troy owns a car then it is "Troy's car". However, there is some debate about what to do if Sebas owns a car: both "Sebas' car" and "Sebas's car" seem to be acceptable.

The thing to watch out for is plurals. If you are correcting mistakes made by a single author then you are correcting "the author's mistakes", but if there were several authors involved then you are correcting "the authors' mistakes". However, for plurals that do not include an "s" you still add an "s". If people are making mistakes then they are "the people's mistakes".