> On Wed, 10 Dec 2008 21:37:05 +0100, "Thorsten Leemhuis"
> [...]
>> I for one read most of the important fedora lists. But not all -- I for
>> example stopped reading ambassadors and marketing some years ago and
>> would like to rely on FWN to highlight important discussions in a short
>> manner (if there are any); if I then find the topic interesting I'll
>> jump to the list to read the details
> To be honest I have no idea what our reader profiles really are, but
> given that you're one of the few people to give feedback I'm going to go
> with a trial run of what you suggest and then see if we get masses of
> complaints.
Maybe asking users more directly for their option before testing a
different way might be better, because some people always will complain
if you change something -- even if the cange definitely makes things
better for the masses (not sure if the latter is the case here; it's
just meant as general comment)
> [snip]
>>> I would prefer all the links at the bottom of each item.
>> For text only: Sure. But in HTML/wiki I'd prefer to not see them at all.
> OK, we can do that I think. Just a numbered reference which is an
> anchor to the actual link should be something we can do. But for the
> plaintext mailing we'll append the links below each item instead of
> below each paragraph.
Sounds great to me!
> [...]
>>>> are likely a whole less work and they even
>>>> get them translated because they are shorter/focus on the more important
>>>> things.
>>> "More important" than what? My impression is that you'd prefer it if
>>> there were no "Developments" or "Virtualization" sections and simply a
>>> list of what gets posted to @fedora-announce and some entries from
>>> Planet.
>> *I* for one would like to see the ten or twelve (?) most important
>> things *for the overall project* mentioned briefly and (in addition)
>> quick one-line links to other things that are also important, but do not
>> qualify as "most important".
> Hmmm. It's going to be a difficult judgement call to be able to discern
> what is important "for the overall project".
Sure, it's not easy.
> I don't think I'd want to try to do that.
Face it: You already did and do some decisions of what's important or
not by picking some discussion and ignoring others; and you chose which
project areas to report about while others don't get much attention in
the FWN.
Take EPEL for example, which is not mentioned once in the last ten
report afaics. Okay, not much happened in the past ten weeks, but 166
new packages in EPEL5 proper IMHO would have been worth a few words and
a link:
https://www.redhat.com/archives/epel-devel-list/2008-December/msg00005.html
But that not your fault, as I suppose nobody told you about it. It's
just meant as example.
> Nearly everything on Developments has implications for
> the overall project. I see the Developments beat as more or less
> following where the interest and action is, mainly by the volume of
> posting on a topic. If you, or anyone else, can spot things which should
> definitely be covered for an upcoming issue then I'd appreciate a
> friendly ping to make sure I'm on the job.
When I wrote the EPEL reports back ages ago I tried a few times, but it
often failed (which is not your fault; and note, I'm not involved that
much anymore in EPEL, it just serves as random example).
> I've tried to do things like
> cover FESCo deliberations a little so that the context of some of the
> discussions makes sense to readers who *don't* follow all the important
> threads, let alone IRC channels. I've realized several weeks that
> important topics have been neglected, but that's only in retrospect.
Sometimes it's IMHO better to neglect important, but not very important
topics -- otherwise you write to much in the end that nobody wants to
read because it's to long which scares people (like me) away.
>> The Art team for example does great work, but most of the stuff in
>> http://fedoraproject.org/wiki/FWN/LatestIssue#Artwork afaics is only of
>> interest for members of the Art team. Hence it should not be in the FWN;
>> instead it could go to their list if they want to sum up things.
> I really don't think I agree with that. I like reading about what goes
> on in the Art team as I'm not subscribed to their lists (nor am I going
> to subscribe), so it's valuable to me to get a quick overview of what
> they do.
You got me wrong here. I'm fine with reports from the art team and I
want to read about the important things they do for the reasons you
gave. But for me the current section is to long and to detailed -- the
topics "Postprocessing in Icons" and "FirstAidKit Artwork" in FWN155 for
example.
> Similarly with Virtualization there is no way that I could
> digest the vast amount of change that's happening and I don't want to be
> on another list, so getting a weekly digest is absolutely invaluable to
> me.
And for others it might be EPEL, Trans-list, OLPC or one of the other
dozens of project areas. If you cover them all that in-depth then the
FWN get ever longer and more hard to read. Setting a rough length limit
could prevent that.
> [...]
> I'm thinking about what you've said and will certainly
> take a shot at making the Development beat more concise.
thx
> Apart from
> anything else it's a mammoth effort to put it out each week.
I know. Many thx for your work.
> [...]
Cu
knurd
_______________________________________________
Fedora-news-list mailing list
Fedora-news-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-news-list
![[please load images]](http://www.heise-online.co.uk/icons/ho_logo_newsletter.gif "[please load images]"){kind=icon}
![[please load images]](http://www.heise-online.co.uk/icons/newsletter/icon_print.gif "[please load images]"){kind=icon}
![[please load images]](http://www.heise-online.co.uk/icons/newsletter/news/icon_send.gif "[please load images]"){kind=icon}
![[please load images]](http://www.heise-online.co.uk/icons/newsletter/icon_news_index.gif "[please load images]"){kind=icon}
![[please load images]](http://www.heise-online.co.uk/icons/newsletter/icon_news_properties.gif "[please load images]"){kind=icon}
