<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:creativeCommons="http://backend.userland.com/creativeCommonsRssModule"	>
<channel>
	<title>Comments on: Pulse</title>
	<atom:link href="http://blogs.gnome.org/shaunm/2008/03/03/pulse/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.gnome.org/shaunm/2008/03/03/pulse/</link>
	<description>Fourteen hours to save the Earth</description>
	<lastBuildDate>Thu, 02 Feb 2012 10:02:40 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: shaunm</title>
		<link>http://blogs.gnome.org/shaunm/2008/03/03/pulse/comment-page-1/#comment-42</link>
		<dc:creator>shaunm</dc:creator>
		<pubDate>Tue, 04 Mar 2008 00:01:58 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/shaunm/2008/03/03/pulse/#comment-42</guid>
		<description>I&#039;ve thought about trying to identify translation and documentation commits.  I do know what domains and documents are in the module, and which directory those are in.  So I could see if all the files of a given commit are in a particular directory.  I&#039;m not sure I&#039;d want to use only code commits for the graph though.  To me, it&#039;s interesting to see the effect translations have on the total activity.  But certainly being able to filter out non-code commits in the activity listing could be useful.

As for developers, maintainers have a star next to their names.  Other types of developers will be identified by other badges.  It&#039;s just that, at the moment, the MAINTAINERS file is the only source of information for developers.  That will certainly change once I get bugzilla stuff integrated.  Suggestions for other sources of developers are welcome.  (You can see, for instance, on documentation pages we have maintainers, authors, editors, publishers, and generic developers.  But I don&#039;t have icons yet for anything other than maintainers.)</description>
		<content:encoded><![CDATA[<p>I&#8217;ve thought about trying to identify translation and documentation commits.  I do know what domains and documents are in the module, and which directory those are in.  So I could see if all the files of a given commit are in a particular directory.  I&#8217;m not sure I&#8217;d want to use only code commits for the graph though.  To me, it&#8217;s interesting to see the effect translations have on the total activity.  But certainly being able to filter out non-code commits in the activity listing could be useful.</p>
<p>As for developers, maintainers have a star next to their names.  Other types of developers will be identified by other badges.  It&#8217;s just that, at the moment, the MAINTAINERS file is the only source of information for developers.  That will certainly change once I get bugzilla stuff integrated.  Suggestions for other sources of developers are welcome.  (You can see, for instance, on documentation pages we have maintainers, authors, editors, publishers, and generic developers.  But I don&#8217;t have icons yet for anything other than maintainers.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Johannes</title>
		<link>http://blogs.gnome.org/shaunm/2008/03/03/pulse/comment-page-1/#comment-41</link>
		<dc:creator>Johannes</dc:creator>
		<pubDate>Mon, 03 Mar 2008 23:35:54 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/shaunm/2008/03/03/pulse/#comment-41</guid>
		<description>Really cool!

For the activity view/commits I would really like to see a split between translation and code. For me as developer, translation updates are not that interesting so it would be good to be able to filter them.

Another thing is that you should either rename &quot;Developers&quot; to &quot;Maintainers&quot; or at least import the developer list from bugzilla.

But really rocking!</description>
		<content:encoded><![CDATA[<p>Really cool!</p>
<p>For the activity view/commits I would really like to see a split between translation and code. For me as developer, translation updates are not that interesting so it would be good to be able to filter them.</p>
<p>Another thing is that you should either rename &#8220;Developers&#8221; to &#8220;Maintainers&#8221; or at least import the developer list from bugzilla.</p>
<p>But really rocking!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: PMPope</title>
		<link>http://blogs.gnome.org/shaunm/2008/03/03/pulse/comment-page-1/#comment-40</link>
		<dc:creator>PMPope</dc:creator>
		<pubDate>Mon, 03 Mar 2008 22:34:10 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/shaunm/2008/03/03/pulse/#comment-40</guid>
		<description>Awesome Feature, Shaun! KUGW!</description>
		<content:encoded><![CDATA[<p>Awesome Feature, Shaun! KUGW!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: shaunm</title>
		<link>http://blogs.gnome.org/shaunm/2008/03/03/pulse/comment-page-1/#comment-39</link>
		<dc:creator>shaunm</dc:creator>
		<pubDate>Mon, 03 Mar 2008 21:43:30 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/shaunm/2008/03/03/pulse/#comment-39</guid>
		<description>Marko, while maintainers do tend to know everything developer-related about their projects, Pulse can be a good way for them to see how the documentation and translation teams are keeping up with them on their modules.  Even for the things the maintainers know about, though, the Pulse page for their module can serve as a quick start page with links to things they want to see when hacking.

But your point is taken.  The real value lies in presenting information to people who aren&#039;t already in the know.  And that includes, in large part, new and occasional developers.

Blog aggregation is something I&#039;ve thought about as well.  I wouldn&#039;t want to turn Pulse into a full-blown Planet, but links to recent blog posts would be nice.  Note that a number of projects have their own blogs, independant of the blogs of their maintainers, and we could feed these into project pages.

I have a fairly flexible mechanism for putting data into Pulse manually.  My general workflow is often to put data in that way, write some processing code, and then figure out how I could get that data automatically.  A few things just have to be entered manually, as they&#039;re the starting point for everything else.</description>
		<content:encoded><![CDATA[<p>Marko, while maintainers do tend to know everything developer-related about their projects, Pulse can be a good way for them to see how the documentation and translation teams are keeping up with them on their modules.  Even for the things the maintainers know about, though, the Pulse page for their module can serve as a quick start page with links to things they want to see when hacking.</p>
<p>But your point is taken.  The real value lies in presenting information to people who aren&#8217;t already in the know.  And that includes, in large part, new and occasional developers.</p>
<p>Blog aggregation is something I&#8217;ve thought about as well.  I wouldn&#8217;t want to turn Pulse into a full-blown Planet, but links to recent blog posts would be nice.  Note that a number of projects have their own blogs, independant of the blogs of their maintainers, and we could feed these into project pages.</p>
<p>I have a fairly flexible mechanism for putting data into Pulse manually.  My general workflow is often to put data in that way, write some processing code, and then figure out how I could get that data automatically.  A few things just have to be entered manually, as they&#8217;re the starting point for everything else.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Marko Anastasov</title>
		<link>http://blogs.gnome.org/shaunm/2008/03/03/pulse/comment-page-1/#comment-38</link>
		<dc:creator>Marko Anastasov</dc:creator>
		<pubDate>Mon, 03 Mar 2008 21:12:30 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/shaunm/2008/03/03/pulse/#comment-38</guid>
		<description>I think that this kind of a system would be most helpful to contributors (to some degree), and anybody who wants to check out what&#039;s going on with the development of a certain project. I&#039;m not sure how really useful would it be to maintainers, who already &quot;know everything&quot; about their projects, except that it is indeed nice to occasionally take a look at such a unifying &quot;collection of random interesting facts&quot;.

So then it would be definetely good to show most recent mailing list posts, with links to complete archives, and latest bugzilla entries. A separate page could show links to all components etc. Perhaps also a post or two from developer&#039;s blogs - or an even more clever way would be to display only posts tagged as &quot;project&quot;; you would just need to announce it somewhere so that everyone would start doing it properly. Although I&#039;m not sure if it would be possible to do it completely automatically - developers would probably need to create some &quot;GNOME Pulse&quot; profile - integrated with existing infrastructure? - and specify feed URLs.</description>
		<content:encoded><![CDATA[<p>I think that this kind of a system would be most helpful to contributors (to some degree), and anybody who wants to check out what&#8217;s going on with the development of a certain project. I&#8217;m not sure how really useful would it be to maintainers, who already &#8220;know everything&#8221; about their projects, except that it is indeed nice to occasionally take a look at such a unifying &#8220;collection of random interesting facts&#8221;.</p>
<p>So then it would be definetely good to show most recent mailing list posts, with links to complete archives, and latest bugzilla entries. A separate page could show links to all components etc. Perhaps also a post or two from developer&#8217;s blogs &#8211; or an even more clever way would be to display only posts tagged as &#8220;project&#8221;; you would just need to announce it somewhere so that everyone would start doing it properly. Although I&#8217;m not sure if it would be possible to do it completely automatically &#8211; developers would probably need to create some &#8220;GNOME Pulse&#8221; profile &#8211; integrated with existing infrastructure? &#8211; and specify feed URLs.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: shaunm</title>
		<link>http://blogs.gnome.org/shaunm/2008/03/03/pulse/comment-page-1/#comment-37</link>
		<dc:creator>shaunm</dc:creator>
		<pubDate>Mon, 03 Mar 2008 21:02:58 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/shaunm/2008/03/03/pulse/#comment-37</guid>
		<description>ATOM, RSS, RDF, and whatever other machine-readable formats would help are certainly on the radar.  Pulse could then function as a base body of knowledge upon which other systems could be built.  I haven&#039;t yet added these things because, well, there&#039;s a lot of information in Pulse, and it&#039;s not yet clear to me what would be most useful.</description>
		<content:encoded><![CDATA[<p>ATOM, RSS, RDF, and whatever other machine-readable formats would help are certainly on the radar.  Pulse could then function as a base body of knowledge upon which other systems could be built.  I haven&#8217;t yet added these things because, well, there&#8217;s a lot of information in Pulse, and it&#8217;s not yet clear to me what would be most useful.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Christian Hergert</title>
		<link>http://blogs.gnome.org/shaunm/2008/03/03/pulse/comment-page-1/#comment-36</link>
		<dc:creator>Christian Hergert</dc:creator>
		<pubDate>Mon, 03 Mar 2008 19:24:28 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/shaunm/2008/03/03/pulse/#comment-36</guid>
		<description>Can we get an ATOM or RSS feed?</description>
		<content:encoded><![CDATA[<p>Can we get an ATOM or RSS feed?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
<!-- This Quick Cache file was built for (  blogs.gnome.org/shaunm/2008/03/03/pulse/feed/ ) in 0.16483 seconds, on Feb 10th, 2012 at 4:28 pm UTC. -->
<!-- This Quick Cache file will automatically expire ( and be re-built automatically ) on Feb 10th, 2012 at 5:28 pm UTC -->
