[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-promo
Subject:    Re: [kde-promo] dot and kdenews
From:       Jos Poortvliet <jospoortvliet () gmail ! com>
Date:       2010-05-10 8:21:56
Message-ID: AANLkTik0xBgFodYDb7n2sNl3AIatrnanEV6jDqW0UHRS () mail ! gmail ! com
[Download RAW message or body]

On Sun, May 9, 2010 at 10:40 PM, Stuart Jarvis <stuart.jarvis@gmail.com> wrote:
> (Mike, if you wonder why you're on cc, see the 3rd paragraph from the bottom)
> 
> With regard to minor and devel releases, we could consider a "release digest",
> say weekly, that just very briefly lists the releases from the previous week
> that didn't merit their own article and links to blog posts or announcements
> elsewhere. We'd need a mechanism to make this quick and easy, say you only get
> your release in if you email the dot address with the required details that
> week.
> 
> > Hmmm. Technically, we're still the outlet we were before - anyone can
> > send in articles, and while we might have become slightly more
> > restrictive, I don't feel we're closed down for 'less official'
> > stories. You're right in mentioning less important release
> > announcements, but those can be put on either individual websites and
> > blogs - aggregated on the planet (and buzz.kde.org).
> > 
> I'd be happy to see more of the old-style link to other news site articles
> (with just a short summary). For me, they don't happen for a couple of
> reasons:
> - I kinda lack the time to do them - I'm more motivated to work on
> editing the other stories or putting them together
> - The Dot rules (a second review etc) though sensible can mean it takes a
> while to get these out, by which time they might be old news. It's tricky, on
> the one hand making sure we keep quality up and on the other not making it too
> bureaucratic.
> 
> So the second influences the first a bit - I can't just write, publish and
> forget... Would we favour saying any editor can write a short summary to an
> article on another site and publish it immediately without review or
> discussing scheduling? So we wouldn't care if one of these mini articles
> appeared on the same day as a big one. Less chance for typos, probably no pics
> and only one link... Is that how it used to work?

Yes, it is, and yes, I agree. I rarely feel the urge to write such
small things but if others do - please go ahead and indeed, publish
them, as they're of little consequence. However. They CAN push
important articles down - I have no problem publishing them shortly
BEFORE an important article, but once that is out it would be a shame
to move it down too quickly. So as long as we can make sure that
doesn't happen - publish away.

> Ultimately, we could set up a separate category for these and allow them to be
> shown/hidden with respect to reader preferences and maybe send them to a
> separate RSS feed as the Dot gets syndicated to Facebook and Identica etc.
> 
> Me nudges Mike Arthur who was talking about dot categories/tags a while ago
> ;-)

Frankly I have no problem having them just on the dot. I doubt ppl
would mind or want to filter them out... Still, if Mike wants to make
a difference here, let'em go ahead ;-)

> > I wonder if any, let alone a lot independent stories might come to
> > this kdenews.org - unless we turn it into an automatic aggregation of
> > news... Still, if you or anyone feels we might solicit more input from
> > outside of the close group of KDE people, this might be the way to do
> > it and I would support it.
> 
> An automated aggregation could be cool - in that case I'd favour having it on
> another site such as kdenews.org as there would be quite a lot of stuff

Yep, absolutely... But again, we have buzz.kde.org (say you filter out
the high-trafic things like microblogs) and it could be adapted for
this purpose.

Cheers,
Jos

> Cheers,
> stu
 
_______________________________________________
This message is from the kde-promo mailing list.

Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on \
or temporarily stop your subscription.


[prev in list] [next in list] [prev in thread] [next in thread]