Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] "Project meta data is out of date for..." messages

I second that. I for one would probably just forget to update the meta data. And the validation just caught a typo on my project so I just need the check.

Achim

On 08.08.2011, at 23:36, Mary Ruddy wrote:

+1 to continuing to send out the messages to project leads only and adding a validate button
 
From: eclipse.org-architecture-council-bounces@xxxxxxxxxxx [mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx] On Behalf Of Neil Hauge
Sent: Monday, August 08, 2011 5:23 PM
To: eclipse.org-architecture-council@xxxxxxxxxxx
Subject: Re: [eclipse.org-architecture-council] "Project meta data is out of date for..." messages
 
In my experience these notifications are worth keeping around.  I worry that without the notifications, many projects would forget to update their metadata early in the release cycle (as opposed to 1 week before a release), and as a result lose most of the benefit of maintaining the metadata in the first place.   If stale project metadata becomes the norm there won't be much of a reason to continue capturing the information.

That said, perhaps an "opt-out of notifications" mechanism could be implemented in conjunction with the Validate button for projects that don't want or need the nudging?   Running less often also sounds reasonable, maybe 4 times a year, just to make sure the different release schedules of Eclipse projects are accommodated.  Sending notifications only to the specific project leads also sounds like a reasonable way to address the clutter issue.

Neil


On 8/8/2011 3:28 PM, Mik Kersten wrote:
+1 for the validate button if there are cycles to make that happen or if it can reuse the existing feature (eg, if validating auto-sends to the project lead or specified email address).
 
But overall I’m leaning even more in John’s direction that these do provide utility when running correctly.  Perhaps not as much for Ed, but Ed is likely to be way more on top of this than others.  On the Mylyn projects, I have repeatedly witnessed those updates trigger fixes.  I don’t think we should optimize reducing noise for projects that will never keep their metadata up-to-date at the cost of removing a useful trigger for those who want to, but are not quite on top of it.
 
Mik
 
--
Dr. Mik Kersten
Tasktop CEO, Mylyn Lead, http://twitter.com/mik_kersten
Assistant: zoe.jong@xxxxxxxxxxx, +1-778-588-6896, Skype: zoe.e.jong
 
From: eclipse.org-architecture-council-bounces@xxxxxxxxxxx [mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
Sent: August-08-11 12:24 PM
To: eclipse.org-architecture-council
Subject: Re: [eclipse.org-architecture-council] "Project meta data is out of date for..." messages
 

I'm torn on this. It does have a fairly high noise-to-signal ratio but often it does point out valid omissions. Having recently done metadata setup for a new project, I definitely appreciated the validation that everything was set up correctly. As Ed suggests, having a button where I can validate the data myself without widely broadcasting the results would be handy. Maybe that, in combination with running it automatically once or twice a year would be enough. 

John 

08/08/2011 02:02 PM

Please respond to
"eclipse.org-architecture-council"        <eclipse.org-architecture-council@xxxxxxxxxxx>
To
cc
Subject
[eclipse.org-architecture-council] "Project meta data is out of        date for..." messages
 




Hey folks.

I tend to regard keeping project metadata/websites/... up-to-date as one
of those "selfish-best interest" sorts of things. That is, projects
should keep this information up-to-date because it is good for the
health of the project.

Every month we have a script that runs to check that certain bits of
metadata are properly specified. Missing, or incorrect entries are
reported via email message to the project mailing list.

Every month, a couple of project leads contact me and the Webmaster
about the messages, generally because something that's being reported
doesn't make sense (e.g. reports that a next release isn't specified
when one seems to have been specified). Every month, the Webmasters and
I spend a good couple of hours chasing down the problem and tend to end
up modifying the check scripts. These good couple of hours could be
better spent doing other more valuable things for the committers and
community.

Most projects--it seems--just ignore these messages anyway.

So... I've been thinking. Is it time to just turn off this notification
mechanism? Or maybe just run it twice a year or something?

Your thoughts are appreciated.

Thanks,

Wayne

-- 
Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton

_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.

 
 
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
 
IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1391 / Virus Database: 1520/3821 - Release Date: 08/08/11

_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.


Back to the top