It's difficult, and would probably end up being misleading at best. Given infinite resources, or at least a lottery winner to hire people and make them do what you want, all information would be available. Barring that, there are maybe 2 people trying to filter complex information from 37 developers (assuming that signature image is up to date) in an understandable way to an audience that ranges from facebook users to kernel hackers (and not necessarily Windows kernel, or x86). Finding time is only part of the problem, deciding who your audience is and what they want to know is far more challenging, especially since this project attracts such a diverse following.
I am not sure why they wouldn't be able to answer questions about their own coding.
maybe then just write down the core files that need to be coded then put a symbol of if its done its being worked on or has not been touched.
Anything that shows some kind of progress and let other know what they could be doing would be better then nothing at all.
You'd be surprised. Especially in straight C, where it is easy to write clever but incomprehensible code, there are so many little things to think about. It's like trying to explain the definition of a word you've read and used many times, but never read an actual definition. Working memory is limited, and sometimes you have to "page out" and can't connect the dots all at the same time. I have a much longer reply that I typed, but basically the people writing code are frequently thinking low-level details, and that doesn't translate well to the average follower, even if they do code for work or other projects.
In the example of USB support, it is difficult to know what files are going to exist until you have a good understanding of the standards involved, and in this case the Windows architecture which supports it. The developer could tell you the core filenames involved, but the value of that information is very low since the files might be rearranged, renamed, split, or merged as more code gets implemented. "USB: 15% implemented" might mean to some people that their mass storage device should work, but to a developer it might mean all of the headers are done but not one line of working code exists. So even that much is hard to do, and harder to agree upon. "USB: 50%" might suggest that your mouse might work, but it could very well mean "Inserting a USB device of any kind will brick your computer, but the .dll works on Windows as long as you only do this...."
In other words, this:
http://xkcd.com/612/There are 37 open bugs returned if you search for "regression" in bugzilla. If the front page of rectos.org announces something is working, then a commit makes it stop working, the project will look silly after 37 times, and that's just what's open right now. It's a work in progress, it's alpha, it's volatile. I posted my sources, I stay as up to date as possible, I read commits from CIA at least twice a day, I update from SVN and build it myself, I occasionally try to find bugs, and yet every newsletter there is something I did not know about, or did not understand at the time. Obviously more information is needed, obviously no one has time to do much more than is being done. At the same time, sometimes there just isn't any progress to report that would matter.
If you haven't been watching commits, Amine Khaldi among others has been rearranging headers to form a more coherent development kit, and those updates just got merged into the main source tree. To the end user, it's just updating about 150 files and no applications will work better or worse, there is nothing of interest to report. Does the average facebook and twitter user want to know that? No, they probably wouldn't have any idea what that means. But for people interested in operating system development and more specifically a replacement operating system, this is a huge effort and very good news indeed. At the beginning of this work, I'm pretty sure Amine would not have been able to say "142 files to alter" and then give gradual updates X% completed and so on. Where do we draw the line?
Whoever compiles the information gets to decide how detailed - If someone wants to compile commit messages and summarize ros-dev chatter, I will volunteer to be your personal technical advisor - the catch is, you have to live up to whatever you requested here or you're on your own. Start by making your own topic, or wiki page, message me occasionally, and keep the updates coming, even if it's just "257 commits this week - no idea what any of it means, but someone's obviously doing something and ros-arm-bringup verbally bitchslapped some people only twice." That information could get merged with developer input by whomever writes the next newsletter, which should be at least a little easier to write with help. At the same time, maybe you can get a good start on summarizing activity for the changelog, removing one of those roadblocks for the next release. (Even if project team hates you and your updates, you can maybe make your own wiki page, and if they like it maybe you get to update pages in the CMS - but I'm just an observer making suggestions so don't think I can grant stuff).
At one time, I knew nothing about Windows and thought it was magic, knew nothing about code or open source - everyone was like that. But we got better
by hto » Fri Mar 12, 2010 9:36 pm 
