INTERACT FORUM
More => Old Versions => Media Center 11 (Development Ended) => Topic started by: JimH on June 15, 2005, 07:25:18 pm
-
It looks like build 293 is it. Speak up now or forever hold your peace.
-
It looks like build 293 is it. Speak up now or forever hold your peace.
...until MC 12 is up for grabs ;D
-
I have no problems....
Well, other then the Ipod Photo support ;D 8)
(Sorry I had to add that) ;D
-
MC itself looks OK, but the UPnP server still has a couple of big problems, at least with the Philips Streamium. (Navigation of audio view schemes gets "stuck" and internet radio streams don't work)
I'd say let it go and fix the UPnP server later...
-
I can hear the fat lady singing.
Matt can get back to his other life too!
Matt Brewing Company
http://saranac.com/brewery/
-
It works for me. My mom is calling me!
-
Totally agree with Myron... get it out and then focus some ressources on the UpnP stuff
-
Release and finetune in 11.1.x
-
In the words of Jay...
"Do it, Doug!"
-
Let it go but finetune in 11.1.x
-
Ready to go, then directly start with version 12 alpha, so we can request new fetaures :-)
-
Well, at least it's a lot more ready than the last time you asked, Jim... http://yabb.jriver.com/interact/index.php?topic=27871.0 You were wondering if 276 was it...and my reply was in part "But it's kind of scary that the list of changes became shorter and shorter these last builds, but became really long again for 276... "
Now the lists seems to be in a roller coaster, from one to ten items or so, so why not quit while you're ahead? ;) Get it out the door, and start brainstorming for 12, I say!
-
In my opinion: Yes.
Generally, JRiver should do what is commercially wise. The most important thing is that the product is stable enough to convince those trial users and perhaps professional reviewers who start evaluating MC11 after they have heard about the new release.
Is the Help fixed to include the latest changes? Newbies do not have other resources before they begin to understand how this forum support works.
We current users know how this works. Release will not change our status.
-
Maybe :-\
Burned music cds are not yet as cleanly as with nero burned, on different playern jump them.
-
I also think it should get out by now, but also support the idea of a release 11.1 to polish some of the unfinished things (such as internationalization, proper handling of images with synching etc.)
It was done before (I think with version 7, 8 and 9). There are always features that are not perfectly implemented and before proceeding to adding new features in a version 12, some final polishing and perfecting in a version 11.1 would really be a great advantage. It gives the company also the impression that they care for refinement of a product.
There were always bad feelings left behind, when users realized that former releases were not refined any longer and development proceeded to the next version and stopped caring for the previous version altogether!
-
I hoped that all its default skins are completed first..
-
It looks like build 293 is it. Speak up now or forever hold your peace.
I would like to see a working progress bar in "Burn CD/DVD" action window during the compilation/transcoding stage either before release or in a .1 tweak, otherwise, it works well for me.
-
Hello? P-p-p-p-p-ping!
-
Yea sure. But build 300 is such a nice round number, why not wait.
-
No one would believe it.
-
MJ8 had 400 builds
-
Well, MJ8 was very stable. Anyway I think MC 11 will be 300. And I'm pretty sure this was planned a long time ago, by the Illuminati, to mock the church...or something...
-
I think the cover art issue is a show stopper. I documented this in .299 and there have been many other reports of problems.
-
I don't know what makes the program "ready", but I can tell you that the number of remaining (known) flaws is small compared to the huge number of features available. I think that anyone trying out the program for the first time will be pleased with the fit and finish, and totally bowled over by the feature set. I also think that the definition of "showstopper" has undergone threshold shift.
-
It's been awhile since there's been a release. Anybody else get the feeling that J River wants 300 to be the final release? ;D
-
When is Done Really Done?
By Peter Clark
Summary: When your idea of a completed task is significantly different from that of your team’s members, you're asking for trouble. In this week’s column, Peter Clark outlines some steps you can take to ensure that everyone on your team understands your expectations when you ask them if they're “done.”
--------------------------------------------------------------------------------
One of the biggest problems I have had over the years with the people who report to me is a fundamental disagreement of what the word “done” means. When I was a brand-new supervisor, I would ask my people how they were doing on whatever tasks they were working on. They would tear themselves away from their computer screens and say, “Fine. I'm almost done.” I would walk away feeling good about them and about the project, confident that they had things covered. A week or two later, I would check in with them again. They would look up at me and say, “Fine. I'm almost done.”
Another variation of this is the high-precision answer. How are you doing? “Fine. I'm 95% done.” The purpose of this degree of precision is to convince the interrogator that everything is under control. In fact, nothing could be further from the truth. I have formulated “Clark’s Law of Misappropriated Precision”: When it comes to estimating completeness, the greater the precision, the greater the inaccuracy. I have been told that an activity was 97% done and required no more than two weeks to complete. I have then waited four months for completion.
The problem isn't that my people are being mendacious. The problem is that we have a disagreement on what the meaning of “done” is. When I, as a manager, say “done” I mean that the task is complete and this person is ready for her next assignment. Therefore, when people say that they are 97% done, I expect that only 3% of the work remains. On a 100-hour task, I foolishly assume that only 3 hours remain and I should be able to assign them something new tomorrow.
What do my people mean when they say “done”? It varies. If I have asked them to create a new module, “nearly done” may mean:
I have thought about it, and I am ready to start coding.
I have coded it, and I am ready to think about testing it.
I have tested it, and I just have to fix all of the bugs.
I am tired of working on this, and I am ready for something new.
I have found a horrible bug, and I am ready to rewrite the module from scratch.
Projects can float along in a dream-like haze for months in this manner. Oftentimes you don't know whether something is really done until integration. When you go to put all the pieces together, you then find out that a lot of them are missing or wrong.
There are things you can do to avoid this. For common tasks, like coding a module, I create a description of the meaning of “done.” This includes:
A description of what is included in this activity: for example, coding, unit testing, inspection, documentation of insertion of the module into the revision control system
A brief list of related activities that are not included in this activity, to prevent gold plating and distractions
A list of any predecessor tasks to this one
A list of inch stones, along with the percentage of the overall task that is finished when that inch stone is complete
Predecessor tasks are important because your staff will often jump the gun to work on something that they like. For example, they will begin working on the code before the requirements have been finalized. You need to establish the gate they must pass through before they can start working on a task or your sweet daydream will quickly turn into a nightmare of blown schedules and budgets.
The inch stones are valuable for several reasons. First of all, they serve as a checklist of all of the parts of the task. For example, programmers almost always view coding as the largest part of the task. When coding is done, they believe that they are “97% done.” The checklist reminds them that there are other, equally important, tasks that must be completed.
Inch stones are also invaluable in overall project tracking. Take, for example, a programmer who has burned 50% of the budget, but has completed only 30% of the inch stones. You can then multiply the remaining budget by 5/3 to get an expected cost at completion for that task. You can then use this to adjust your completion date for the scheduled task.
Inch stones are binary – they are either done or not done. Also, the completion criteria for inch stones should be extremely simple and easily verified. For example, the completion criteria for unit testing a module might be that the unit test plan has been executed and the unit test record checked into the revision control system. When receiving status on inch stones, you should repeatedly verify that these criteria have been met until it becomes reflex for your people to complete them.
A disagreement over the meaning of done is always a recipe for disaster as it allows you to proceed as though everything is fine, when in fact it is not. You often don't learn of your problem until it is too late to do anything about it.
-
Hah! I foiled their evil plans! Since they were exposed, they had to jump to 301 instead of 300! Victory! ;D