LeafLabs Garden » Topic: An up-to-date Maple buglist with priority, description and issue/case #

LeafLabs Garden » Topic: An up-to-date Maple buglist with priority, description and issue/case # http://forums.leaflabs.com/topic.php?id=165 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:12:43 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php gbulmer on "An up-to-date Maple buglist with priority, description and issue/case #" http://forums.leaflabs.com/topic.php?id=165#post-1474 Thu, 30 Sep 2010 14:13:01 +0000 gbulmer 1474@http://forums.leaflabs.com/ mbolivar - I've registered, got the conformation email, but the link to activate gthe account seems to have an error. The URL starts: <a href="http://redmine.leaflabs.com:3000/account/activate?token=" rel="nofollow">http://redmine.leaflabs.com:3000/account/activate?token=</a> but that doesn't work, e.g. safari can't find the server The ':3000' needs to be deleted <a href="http://redmine.leaflabs.com/account/activate?token=" rel="nofollow">http://redmine.leaflabs.com/account/activate?token=</a> then it works. mbolivar on "An up-to-date Maple buglist with priority, description and issue/case #" http://forums.leaflabs.com/topic.php?id=165#post-1454 Thu, 30 Sep 2010 02:03:22 +0000 mbolivar 1454@http://forums.leaflabs.com/ Hey all! As promised, we've opened up our bug tracker (we use redmine): <a href="http://redmine.leaflabs.com/" rel="nofollow">http://redmine.leaflabs.com/</a> The issues lists you see there are the same ones we use internally, so they are always up-to-date. You can register for an account, which will let you add notes to issues, and will also let you edit the wiki pages for our projects. Right now, the wiki basically doesn't exist, but we're hoping you guys will find a use for it -- the forums are getting so active, it's not really practical to search them as a source of information anymore. Let us know what you think; any feedback is most welcome. - The LeafLabs team poslathian on "An up-to-date Maple buglist with priority, description and issue/case #" http://forums.leaflabs.com/topic.php?id=165#post-1189 Mon, 13 Sep 2010 12:32:48 +0000 poslathian 1189@http://forums.leaflabs.com/ We will check all this stuff out. We have been debating what to setup to be public facing. Our current ticket tracker (redmine) is pretty handy, it doesnt integrate with the repo (unlike github or jira) which would be nice. The setup cost and the amount of ticket-porting necessary to switch to Jira is holding us back from that option right now, but I think it is the favored platform. gbulmer on "An up-to-date Maple buglist with priority, description and issue/case #" http://forums.leaflabs.com/topic.php?id=165#post-1150 Thu, 09 Sep 2010 20:03:24 +0000 gbulmer 1150@http://forums.leaflabs.com/ poslathian - we were low-tech. We emailed two spreadsheets to each of our lead users. As I remember, one contained a consolidated list of the feature requests we'd received, and the other defects which we felt could be triaged to a low enough priority to be pushed beyond the next release cycle unless someone voted for it. We issued a 'return date' at the same time. We were on 6+ month cycles, and I think we timed the response period at, about, 3 weeks (with an explanation well-ahead of time about the process), so the "discussion to concensus" took about 3 days, and still happened early enough to strongly guide development. We met with the lead users who were mostly our early adopters, either as part of our conference, or at a specially organised event (we paid some of the expenses). This was important then to get the users full attention (they were important, and very busy, people, but this was a good event for them to strongly influence our direction). This isn't necessary anymore :-) I have taken only the briefest skim of Google moderator. My main reservation would be triaging folks who have, or are going to spend money, from those who just like playing with your head :-) I also briefly skimmed UserVoice, As amir.hadzic wrote, UserVoice looks much closer to the process we used, though it seems to limit the number of votes in a way which may be too arbitrary. This may not be an issue if you give UserVoice muh-knee (hmmmmm?-) I am not an expert in these products, but our users did seem to like the process we used. We got some very positive feedback from them. Several said it was a very good process, better than most other software suppliers of that time (early-mid '00). They did support the process with significant manpower and thought, which, to me, spoke volumes of its effect. Amir Hadzic on "An up-to-date Maple buglist with priority, description and issue/case #" http://forums.leaflabs.com/topic.php?id=165#post-1101 Wed, 08 Sep 2010 01:54:52 +0000 Amir Hadzic 1101@http://forums.leaflabs.com/ You could use <a href="http://uservoice.com/">UserVoice</a> od <a href="http://www.google.com/moderator/">Google Moderator</a>, depending on your requirements. If you want to limit the number of votes each user gets, then go with UserVoice. If that's not required (but then you can't really know what users see as a priority) then you can use Google Moderator. poslathian on "An up-to-date Maple buglist with priority, description and issue/case #" http://forums.leaflabs.com/topic.php?id=165#post-1100 Tue, 07 Sep 2010 21:22:40 +0000 poslathian 1100@http://forums.leaflabs.com/ gbulmer, this is a very interesting idea. In projects like ours, where developer hours are few but n user enthusiasm is high, I think the voting mechanism might just be the thing. How did you guys implement this? Through some web interface together? or perhaps it was built in to your bug tracker? I confess I know extremely little about github and its features. I dragged my feet over SVN a few months ago but iperry and bnewbold pushed hard for git. I am definitely happy with the git workflow (officially converted). Github is great repo manager for git projects, but I dont know my way around it 100% yet. Ill have to "popped over to github to watch the issue tracker video (which I've never bothered to look at before)" gbulmer on "An up-to-date Maple buglist with priority, description and issue/case #" http://forums.leaflabs.com/topic.php?id=165#post-1091 Tue, 07 Sep 2010 18:50:02 +0000 gbulmer 1091@http://forums.leaflabs.com/ Stephen - very good points, I also feel LeafLabs have produced an excellent piece of work. I should confess, better than I had expected for a first product. Andy - I strongly agree, a more public issue tracker would help. I try to read every post, but I have missed a couple and wasted time as a result. But, on balance, I am willing to suffer that for now because the Maple is so close to my path. poslathian - I've just popped over to github to watch the issue tracker video (which I've never bothered to look at before). It looks like a very good start. I'd like to help by mentioning a technique I learned (while I worked in your fair city of Cambridge) for prioritising, which we found users quite liked. We gathered enhancements and proposals for functionality, as well as bugs. If there were 100 topics to prioritise, each user got, say, 40 votes to allocate. The number of votes was indicative of the amount of resources we could afford, and acknowledged that we could not do everything in one development 'timeslice'. Users could put all 40 votes on one topic if it was critical to them. They could put one vote on each of the 40 topics they cared most about. They could favour bug fixing over new functionality, etc. Most people used the votes to indicate their top priorities. We used the process in quite a visible way, and users discussed with each other why someone had ranked a topic so highly. We sometimes found out that interpretations of topics were slightly different, and when clarified, it helped everyone. When things were difficult, for example everyone had disjoint favourites, we could have rational discussions about the timescales and costs, and that seemed to help too. We asked people to cast their votes by a deadline, then discuss and reach consensus in a few days. I am not suggesting you do this right now. I'm only giving an example, and suggesting that as you move forward, their may be simple approaches which can help clarify topics, and get to even better solutions within tight resource constraints. A good process around priorities and direction might add quite a lot of value for yourselves and the growing Maple community. poslathian on "An up-to-date Maple buglist with priority, description and issue/case #" http://forums.leaflabs.com/topic.php?id=165#post-1079 Tue, 07 Sep 2010 16:02:09 +0000 poslathian 1079@http://forums.leaflabs.com/ wow, good topic! llandy and stephen, thank you both for being great contributors! I agree that the time has come for a public bug tracker. We maintain one internally, and our workflow pretty much goes forums-> file bug ticket -> clear out bug tickets (fix) -> add to release candidate -> test -> release - for bugs found on the forums anyway. Initially there wasnt a ton of user contributed activity and bug finding, and we decided to keep the tracker private. However, thanks to all the great contributions from users like you, its time to keep a better managed public facing tracker. We will probably not port over all the tickets from our internal tracker to github, but we will discuss and eventually implement a plan to start bugtracking for libmaple/wirish/ide on github. side note - (you win iperry...) StephenFromNYC on "An up-to-date Maple buglist with priority, description and issue/case #" http://forums.leaflabs.com/topic.php?id=165#post-1066 Tue, 07 Sep 2010 09:42:14 +0000 StephenFromNYC 1066@http://forums.leaflabs.com/ Tuesday September 7, 2010 Good morning, leaflabsandy, I am sorry you feel frustrated. From your recent questions, answers, and comments on the leaflabs forums I suspect you have made useful contributions to other hardware/software forums and other open source projects. Being an active member of an open source project is very new to me. Once, I sent a suggestion to an open source software project and to my amazement the feature was added to the next release! Yes, having a bug list (with detailed descriptions and priorities) would be very useful. I would add "bug status" to your wish list of features for a bug list. I like your request for an easy to find "to do" list. Personally, I use "to do" lists to keep my projects on schedule, but I also find them great for helping me see what and when tasks were accomplished. I do not delete items from the list. Completed tasks are simply marked as done (and dated) which allows me to refer back to them in the future. However, as in all organizations, keeping "to do" documentations (both internal as well as public) up-to-date is a challenge. I suspect the leafabs team wishes for longer days. When I am coding or debugging code twenty-four hour days are never long enough. Is it more useful for the leaflabs administrators to spend their time debugging code or updating documentation and "to do" lists? What about the long hours (I hope) being invested in developing Maple native? I do not know how often the leaflabs group meets (or even if the entire group meets in person or simply online) to discuss current problems/assignments/priorities. I do not know the size of the leaflabs team, but I suspect each member of the group wears different hats on different days. I do not know if bnewbold is the primary team member who dedicates a significant amount of time to web site development/maintenance (note: I would suggest adding a "Site Map" to the leaflabs web site). leaflabsandy, I share your disappointment, but mine is tempered by enthusiasm for the Maple project. Last week I began to work my way through the libmaple source code. I was very interested in looking at the changes made to SerialUSB(), because during the last few weeks different users have reported problems related to this function. Based on the github dates, the file with SerialUSB() had not been updated for a while. Initially, the old file dates surprised me since I thought changes were still being done to SerialUSB(), but then I realized changes might be made to the various low level interrupt functions supporting SerialUSB(). Today, I was very surprised when I read on the forums that a partial solution to SerialUSB() problems was found several months ago. I thought the warning on the SerialUSB() documentation about DTR/RTS (data terminal ready/ready to send?) was just a temporary suggestion to help coders with a work-around. I had assumed a more robust SerialUSB() was still in the works and that future documentation would include more OS specific examples and tips about using getDTR() and getRTS() (not just "You may need to experiment with the DTR/RTS logic for your platform and device configuration"). It is possible the DTR/RTS warning is not related to my SerialUSB() problems and that someone at leaflabs is still trying to replicate my problems. However, a tracking system would allow users to know if a bug report was closed (and was not receiving any active attention). I do not know when the Arduino project started, or how long it took the project to reach "critical mass" (which I hope the leaflabs project achieves soon), but the Arduino "news archives" started in the summer of 2005. That puts the project at at least five years old. There is a separate section on the Arduino forum where users can describe bugs and make suggestions: <a href="http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?board=swbugs" rel="nofollow">http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?board=swbugs</a> Recent posts to the Arduino.cc bug forum relate to sizeof() problems. If the Arduino project is still having problems with sizeof() after five years I think the leaflabs group has done well so far. If I am correct, it has been less than a year since the Maple was upgraded to a four-layer board. I do not know the typical size of open source projects. The size of open source hardware projects is probably different than open source software projects. I do not know how many "full time" coders are on a typical open source project. leaflabsandy, remember, in their responses to comments and questions several leaflabs administrators have stated they have day jobs. Yes, I am often disappointed by the Maple documentation (which is improving every week), but I think the leaflabs team has done a great job so far both on the hardware and the software. In a perfect world we would concern ourselves only with the bugs in our own code, but with open source projects it is often confusing why it seems to take a long time to solve "critical" bugs. leaflabsandy, I hope your weekend experiences did not break your enthusiasm for the Maple project. If you post your code which shows problem in the maximum serial baud rate, millis(), and word() the bugs in the functions can be fixed and the code can be use to test all future releases of the libmaple. Contributions encourage better open source projects. I think it was my long lists of spelling and grammar mistakes which convinced the leaflab team to use aspell to check for errors. I am looking forward to the Maple-IDE 0.0.7 software release! Thanks! Stephen from NYC leaflabsandy on "An up-to-date Maple buglist with priority, description and issue/case #" http://forums.leaflabs.com/topic.php?id=165#post-1059 Tue, 07 Sep 2010 06:12:22 +0000 leaflabsandy 1059@http://forums.leaflabs.com/ An up-to-date Maple buglist with priority, description and issue/case number is needed for the Maple. This buglist is badly needed so other users can easily indentify software/hardware issues with the Maple. Having the "parital" buglist buried in github won't cut it! Over the weekend, I fought three software issues that should have been resolved long ago. Max. serial buad rate issue, millis(); and word(h,l); Having a up to date buglist will prevent me and others from "spinning their wheels" in software development. Other users please chime in on this issue.