Are we looking to have another MS or Beta release of .8 anytime soon? Are new features locked and now just working on bugs?
Is there a way to lok at bugs submited at the NOC for just .8?
I think i already mentioned it before, but it would be cool to have a bar graph (like Trac) that shows percentage of bugs submitted and completed to give an idea of what all is currently being worked on/delaying a release.
Watch
GitHub Core
Show your support for Zikula! Sign up at Github account and watch the Core project!
GitHub Modules
- internetking created topic »password problem« 25. May
- mesteele101 responded to »ERR (3): E_USER_ERROR: Smarty error: [in pagesvar:pagesitem2en line XXX]…« 25. May
- mazdev responded to »Pages 2.5.0 and updating - Page not found« 25. May
- ehdwma created topic »Hide "Register new account" and change template to 3 col« 25. May
- mesteele101 responded to »Zikula 1.3.3 - Selecting a category in Pages not working« 25. May
- mdee created topic »How to implement returnpage ?« 25. May
- nestormateo responded to »Fillters in Clip« 24. May
Zikula Blog
- Anatomy of Open Source Projects on Mar 07
- Continuous Review on Mar 01
- Not Invented Here on Feb 24
- How to Contribute Your Code at Github on Jan 13
- 10 Steps to Coding-Nirvana: Tips for Successful Module Writing on Nov 12
- Submitting Bug Report Tickets That Get Results on Aug 17
- Cozi Tricks #1: Syntax Highlighting on Aug 07
Login
New MS or Beta Release of .8?
-
- Rank: Expert
- Registered: Dec 31, 1969
- Last visit: Oct 21, 2009
- Posts: 1437
-
- Rank: Expert
- Registered: Feb 27, 2005
- Last visit: Apr 18, 2010
- Posts: 1577
MACscr
I think i already mentioned it before, but it would be cool to have a bar graph (like Trac) that shows percentage of bugs submitted and completed to give an idea of what all is currently being worked on/delaying a release.
I go back and forth on this concept.
Pro: Having more information about what is being worked and and what we are likely to see and when would make me come back regularly to check. It would prevent me from asking about some things again (and again) (and again) because I am not sure whether or not an issue has been heard or is on the list, because of the lack of consistent feedback.
Con: The devs have limited time and energy and I'd rather have them spend it getting the product finished than talking about getting the product finished. And I think/fear that (no matter how hard they/we try to remember that all those lists and targets are tentative), some people here would have hissy fits if progress seemed to slow down or if targets weren't met or if something that had been listed for the next release got bumped to a later release. And (except when they are mine, or course
), hissy fits are ugly and don't help.
--
Peace
______________________________________
The commonest cause of problems is solutions. -
- Rank: Expert
- Registered: Dec 31, 1969
- Last visit: Oct 21, 2009
- Posts: 1437
Actually the bar graph is just based on open bug tickets, etc. Wouldnt require any additional work on their part. -
- Rank: Expert
- Registered: Feb 27, 2005
- Last visit: Apr 18, 2010
- Posts: 1577
Yes, but...
Every complex problem has a simple solution, but it usually doesn't work....
A bar graph that showed only the total number of bug tickets and the numbers resolved and unresolved would be easy - but I submit it wouldn't provide much information. No, that's not accurate. What I mean is that it wouldnn't supply the information that I would most like to see.
I'm not so much interested in how many bugs have been squashed as I am in being able to tell whether or not the specific several bugs that swarm around ME are high or low (or even present) on the list of bugs to squash - how long will I have to wait or should I submit it as a bug?
--
Peace
______________________________________
The commonest cause of problems is solutions. -
- Rank: Expert
- Registered: Dec 31, 1969
- Last visit: Oct 21, 2009
- Posts: 1437
pheski
Yes, but...
Every complex problem has a simple solution, but it usually doesn't work....
I think thats some of the worst logic i have ever read. I also dont think my idea is a "solution" or "fix all", just something that help everyone out.
There is a reason why Trac is becoming (or is) the most popular project tracking/organization script out there. Im definately not saying we should use it (not a big fan of python, sqllite), but that doesnt mean their arent some good ideas that we can take away from it to better improve things for a large project like this. It also gives everyone a better idea of bugs that are being worked on like i suggested before. How many times have we heard from the devs that a release isnt out because their are a few remaining bugs to be closed out. I also never mentioned a damn thing about release dates. I dont expect them.
edited by: MACscr, Jun 21, 2006 - 11:45 PM -
- Rank: Expert
- Registered: Feb 27, 2005
- Last visit: Apr 18, 2010
- Posts: 1577
Macscr ->
I think we agree totally that it would be useful to know what the devs are working on and what they know about but aren't (yet) working on.
I'm not sure what we disagree about, beyond how easy it would be (or how much tiime is involved) to make this information available and keep it current.
And since I have NO experience using systems to do this, and it sounds as if you do, I apologize if I am way off base.
My perspective is that of someone who has to live off his 'day job' and is trying to do some web stuff/PN/learn coding skills in the time available. I get asked regularly by users of sites/lists to do things to improve the sites/lists. Often these are excellent ideas and individually they may not be big - but cumulatively they add up and compete for time and energy with the rest of my life. So I am picturing a dev having to take time away from fixing a problem in the current Forum search or Ajax functions or adding a function to MS8 in order to set up or trouble shoot a bug tracking display.
Like you, I would dearly love to know what the devs are nearly done with, what they are starting, what is on their to do list. Here we agree. I do worry that their resources are finite.
And though I readily admit that my quote may sacrifice accuracy for cuteness, I don't actually think the quote reflects bad reasoning. A better criticism might be that it clearly falls prey to the very phenomenon is pokes fun of: that problems are often more complicated than we think (or want to think).
--
Peace
______________________________________
The commonest cause of problems is solutions. -
**unknown user**
- Rank: Softmore
- Registered: Mar 16, 2002
- Last visit: Oct 21, 2009
- Posts: 171
Have you seen this ? http://www.dordrak.com/dokuwiki/doku.php?id=postnuke80:developmentschedule -
- Rank: Team Member
- Registered: Mar 18, 2002
- Last visit: Oct 21, 2009
- Posts: 6606
I've moved that link into the new wiki. Of the five items listed for MS2 1, 3 and 5 are about there although nothing is formally frozen at this stage. 2 and 4 are the outstanding items with the categories code getting close to completion - at which point I start adding category support to a module or two and writing the docs as I do.
On the subject of trac - I like this software... and if we hadn't already had the existing investment into gforge then it would be worth reviewing. I like that it ties nicely into subversion.
However it doesn't really match the level of functionality we offer via gforge. It would be fine for running the PostNuke core project but doesn't (and doesn't try...) to offer full project hosting a la gforge. One thing i've never had time to investigate is the project management facilities offered by gforge.
-Mark
--
Visit My homepage and Zikula themes.
- Moderated by:
- Support
