Please Comment on RFEs and test Betas
Brought to you by:
canajun2eh,
yalnifj
Menu
▾
▴
Hello Everyone,
With this release there were new features added that people didn't like or that were a big surprise. You can avoid such surprises in the future by reviewing and commenting on the RFEs. If people don't comment on the RFEs then I am going to program them as they were originally requested unless I have ideas for it, which I will usually add as comments to the RFEs.
The other thing that you can do is try out the beta releases. The new PHPLauncher should make this quite easy because you can just run it as an app on your local computer. The beta releases are also a time to provide feedback on the new features. The more feedback I get before the final release the better the final release will be.
I know that this takes time on your parts to download the beta releases and install them and run them on your gedcoms, but that is what beta releases are for. They provide an opportunity for you to test the new features and comment on them.
So, those of you who have strong feelings about the features of PhpGedView, please comment on the RFEs and try out the betas before the final release so that you don't have to put up with something that you don't like.
Thanks,
--John
Hi John,
Thanks for the info. I'll have a better look at the RFE's in the future!
Now about testing. Since there were only three days between the release of the first 2.60 beta and the final release, there was not much time for testing. As a result, the finals have more functionality :-)))) but also have some bugs :-(((
As I stated in an earlier message, that has left me with 2.52.1 as the last version being suitable for my users, because some fundamental things are not working properly. And that's a waste, because I still think PHPGV is getting better all the time with many very useful functions.
In other words, because PHPGV is growing all the time, it should be good to take some more time for testing, resulting in more error-free finals. And perhaps it's an idea to structure the testing process a bit by splitting it up in parts.
What do you think?
Boudewijn.
What I do is have up to 3 different versions on my server. The links from the main site always point at the stable version. I have a site for alpha and betas. I leave new releases in beta unless I test it. Some of my users test the beta and give me feedback. This prevents sudden surprizes yet still allows me to work with the latest and greatest at my own schedule.
I agree with Boudewijn, that a longer beta testing phase would be an advantage, but I also realize that a longer beta testing phase probably also will send the project down on the activity scale ;-(
best regard
Arne
I agre with Arne, but as a user of (and a tiny bit co-worker on) this product, my choice would be for quality instead of rating......
Regards,
Boudewijn.
P.S. Life is full of dilemma's. It's nearly impossible to keep everyone happy!
There was adiscussion about this a while ago:
https://sourceforge.net/forum/message.php?msg_id=2177427
John agreed that release often and early was the way to go.
Hi Boudewijn,
The reason why it went from beta to final so quickly is because I stopped receiving as many comments on it. I had fixed all of the bugs that were listed and discussed. There was about a day of little activity in the forums about the beta. So from my perspective it was ready. I had it up and running on my site, and it was running well and was very stable.
I also can't stay in beta forever. If I always waited until everything was perfect and all changes were present then you would never get a next release. So a final release will often have a few things that are not as perfect as I would have them. The messaging is an example of this. Other examples are the online editing. There is at least one more release before the online editing features will all be present the way I envision them.
Unfortunately, the program is now beyond me. I can keep up pretty well with bug fixes and the new development, but I cannot fully test all of the features in it whenever I change something. Adding a new feature is likely to break an old feature that I don't use regularly. So I rely heavily on beta testers with different gedcom configurations to tell me when things that they use don't work right. With all of the different configuration options it would take days to test every combination. I need your help.
Not everyone wants to maintain different versions on their server. I hope you will take advantage of the new PHPLauncher to help beta test on your local computers.
I also want to thank everyone who donates their time to PhpGedView. There are a lot of very dedicated users who take a great deal of time out of their lives to be involved in the project.
In the future I will communicate more in the forums before I release a final to give more people chances to test the betas. I've also added an Alpha / Beta bugs tracker for you to post beta related bugs to. Beta bugs will be fixed within a day or two and a new release posted.
I'm not sure how to structure the beta testing process to make it better. I think what is needed is more beta testers and better communication on my part to the testers. I felt that the beta was ready for a final release. So I released it, but I should have asked for confirmation from the beta testers first.
I think it is important to release at least once a month, fully ready or not. Otherwise the project looks stagnant. I can't close bugs and RFEs until they are part of a final release. But I don't want to leave fixed bugs sitting there open for more than a month. They look bad and they "bug" me ;)
So resolutions for the next release are:
1. I will communicate better when I intend to release a final based on the latest beta so that you can have one last chance to comment.
2. I will release more betas so that you can have more time to download and test them.
My requests of you are:
1. to test early and test often
2. be profuse with your comments, the more the better
Thanks for all of your help to make PhpGedView better.
--John
John,
I realize it's difficult to find a balance between development, testing and releasing. Especially in a setting like this, where there is no planning, are no stable resources and no formal milestones. I really admire the way you cope with all wishes, reports, discussions and so on. I think it's a good idea to track the beta-bugs, that will give more survey over what's going on and make the development process more manageable.
From me you can always expect some little time I can spend on testing and translating.
And thanks for your thorough reply on my remarks!
Regards,
Boudewijn.
Hi John
In all fairness I must say, that had you asked me I would have said that ver. 2.60 was mature and ready.
But this time I was so occupied with translation that I hardly had time to anything else, and with respect to the new mail functions I had no way to test it on the webhotel, where mail from PHP doesn't work, and therefore it wasn't until today, when I had my own server rigged up, that I had a chance to play around with the mail parts.
best regard
Arne
Hi John
Here are my thoughts on the subject pro's and con's;
I believe more beta testing time would be a good thing when it comes time to release the final version.
The "pro's" would be less error reports when the final does come out which would be a plus for John so he could spend the time he has working on these problems.
The "con's" would be that a new users might get caught by thinking they will try the latest beta and run into some big problem that was unseen and get upset with the way the program works.
I for one don't know very much about writing PHP scripts and probably never will so when it comes to debugging an error I'm fairly lost. Mostly trial and error which sometimes works. I try to spend as much time as possible testing a new version and reporting my errors which I will start reporting in the bug area.
Here is one idea for others to comment on:
If a section was set up where new beta's were downloadable but was for main testers only which would be the people John gave access to along with a report forum for errors some time might be saved. This way a new user which we all were at one time would only get more user friendly releases which in turn should create less general help form messeges. I realize that this will stop some people from trying the new beta's but from what I experienced when I first starting using phpGedView I was asking questions that were already ask and answered earlier in the forums.
Also by doing this John could release more beta's that had known problems to let others help with the scripting and freeing up some of the time he spends on the program.
Ponder on this:
I have read through the comments here today and there are a lot of good points being made. I'm sure no other program was ever created without a problem or bug it in, if they were then beta testers would be a "myth"
Many Thanks to all who have worked hard to make this a great genealogy program.
Thanks Steve
Hi John,
The RFE is, as I understand, request from users, which has not been aproved by you (?).
You ask us to comment the request, - do you want us to write, if we think a request is a good or bad idea ?, - or do you 'just' want ideas for making the request possible ? (as if all requests will be made at some time).
Maybe you could make a note in the RFE, if you aprove a project, and somebody, has startet working on it ?
Is there a place, where ongoing projects are listet ?
Hope you understand my danish-english...
brgds Jette.
Hi Jette,
An RFE is a (R)equest (F)or (E)nhancement. RFE's are a way of tracking future development. They may be submitted by users or by myself or other developers.
Almost all RFEs will eventually get implemented unless they are impossible to implement, meaning they wouldn't match the gedcom spec, or they would run too slow to be feasible.
I read through all of the RFEs. If the RFE is not possible, then I will comment on it and discuss the request if further details with the submitter to make sure that I understand the request and let them know why it wouldn't be possible. If an RFE won't be implemented then it will be marked as "rejected" or "won't fix" and closed.
Any open RFEs in the RFE list will eventually be implemented as I get around to doing or figure out how to do it ;)
What I want the PhpGedView user community to do is look at the RFEs and add a comment to the RFE if you think it is something that should NOT be implemented, or if you have some ideas about how it should be implemented, or if you think it is a really good idea. I would like comments on whether the RFE should have any configuration parameters and whether it should be on or off by default. I will also use the comments to prioitize my time to what I will implement first. If something generates a lot of dicussion then I will implement it faster.
I want to receive feedback about the concept of the RFE and how you think it should work before I start doing it the way I think it shoud work.
If you think the RFE needs to have a lot of discussion and be brought to the attention of more users than you should post a comment about it in the forum. Then we can have a community discussion about what the RFE should do.
Thanks,
--John
Jette,
The I think John want's you to comment on your thoughts about the RFE.
(RFEs are listed in:
https://sourceforge.net/tracker/?group_id=55456&atid=477082
)
Comment on:
Do you like it? Think it is a step backwards? Think it should be implemented differently?
I am sure your second idea of ideas for implementation would be appreciated as well. John has the final say on RFEs and is not shy about rejecting them, but that rarely happens. Most RFEs get implemented in one way or other. This is why the project has grown so much.