Meeting on January 26, 2009
Agenda
- Attendance
- Announce agenda
- Approve January 12, 2009 Meeting Notes. Ask for review and address any problems seen in the notes.
- Discuss ways to clarify the distinction between bug, enhancement, and new feature.
- Discuss needs for view based coordinate systems.
- Open questions
- Summary and closing
Notes
Attendance
- rforehan
- mconsidi
- raevans
- goffena
- tclarke
- kstreith
- gmartin_cn
- dsulgrov
- plin
- jtobe
Summary
The previous meeting notes were reviewed and approved.
Discussion began on the distinction between bug, enhancement, and new feature. Enhancement and new feature both involve the addition of new functionality. There were a few ideas as to how to distinguish but the general feeling is that they differ by scope. Perhaps a new feature is for items which generate a new formal requirement (to the SRS). Others felt that enhancements extend existing functionality and features add totally new functionality. Some felt that the difference should be based on amount of effort needed to implement new capability. There seemed a general consensus that bug wasn't too difficult to distinguish and it involved repair to existing functionality. A couple of attendees brought up the idea of removing enhancement. This was discussion at the January 12, 2009 meeting and a unanimous vote (6-0) indicated that the enhancement type should not be removed. If new information is available indicating that the type should be removed, the issue can be brought up again at a later date. This discussion was taking a while and it was decided to move it to the dev@opticks.ballforge.net list.
There was discussion on the requirements for view based coordinate systems. The new feature will attach a coordinate system to a view instead of using the coordinate system of the primary raster layer. There were questions as to what the coordinate system could be. There are pixel based systems and geo based systems. Should different projections and datums be allowed? General agreement is that there should be a default system which might be a user option. Additional points needing clarification involve translation of values. Will a georeference plug-in attached to a raster element need to handle all the translations or just translation from raster element pixels to a specified system. Additional suggestions can be found in the logs and will be considered when the initial design is formally written up.
Decisions
Logs
| 14:04:33 | rforehan | Here |
| 14:04:37 | mconsidi | here |
| 14:04:38 | raevans | here |
| 14:04:46 | goffena | here |
| 14:04:51 | tclarke | here |
| 14:05:26 | kstreith | here |
| 14:05:32 | tclarke | # Attendance |
| 14:05:33 | tclarke | # Announce agenda |
| 14:05:33 | tclarke | # |
| 14:05:33 | tclarke | Approve January 12, 2009 meeting notes. Ask for review and address any problems seen in the notes. |
| 14:05:33 | tclarke | # Discuss ways to clarify the distinction between bug, enhancement, and new feature. |
| 14:05:33 | tclarke | # Discuss needs for view based coordinate systems. |
| 14:05:34 | tclarke | # Open questions |
| 14:05:36 | tclarke | # Summary and closing |
| 14:05:46 | tclarke | ok, take a quick look at https://opticks.balldayton.com/cometwiki/12Jan2009 |
| 14:05:54 | tclarke | and see if there are any problems with the notes |
| 14:06:45 | tclarke | ok, no problems so we'll accept last meeting's notes |
| 14:06:59 | gmartin_cn | here - sorry, late |
| 14:07:07 | tclarke | the next item is re: the different jira issue types |
| 14:07:26 | tclarke | there's often some confusion and potential overlap with the three types: bug, enhancement, and feature |
| 14:07:33 | tclarke | more specifically with enhancement and feature |
| 14:07:39 | *** | jcouvuts (jcouvuts!i=0cbc9d81@gateway/web/ajax/mibbit.com/x-da528a943c5ba2b6) has joined #opticks |
| 14:08:14 | tclarke | bugs are reported problems with existing functionality |
| 14:08:28 | *** | jtobe (jtobe!n=jtobe@12.188.157.129) has joined #opticks |
| 14:08:32 | tclarke | or missing functionality that is documented in an existing feature's design and is simply missing |
| 14:08:46 | tclarke | the question is, what makes an enhancement vs. a feature |
| 14:09:12 | tclarke | as far as jira workflow is concerned, enhancement uses the bug workflow which has fewer steps |
| 14:09:17 | tclarke | and is intended for smaller changes |
| 14:09:36 | tclarke | feature has 3 main "loops" the Feature Acceptance loop, Design loop, and Implementation loop |
| 14:09:54 | tclarke | each refines the estimates, etc. |
| 14:10:05 | tclarke | any thoughts on how to clarify or better define the distinction? |
| 14:10:26 | tclarke | those who just joined, please respond with "here" so we can list you in the attendance for this meeting |
| 14:10:36 | dsulgrov | here |
| 14:10:37 | tclarke | we'll be discussing geocentric views next |
| 14:10:43 | rforehan | Does a feature add new requirements and an enhancement only add functionality? |
| 14:11:13 | tclarke | one possible distinction is the "SRS distinction" It's a feature if it should be added to the formal requirements doc |
| 14:11:23 | tclarke | but I think that can be a little circular |
| 14:11:23 | gmartin_cn | To me, feature vs. enhancement is partially a size issue - I expect new features to add new requirements and/or a significant amount of code. |
| 14:11:33 | tclarke | i.e. how do you determine if it should have a new formal requirement? |
| 14:12:03 | tclarke | gmartin_cn: agreed...I think it's pretty clear on a lot of issues but we're not clear on the mid sized features |
| 14:12:38 | tclarke | and not sure if there should be a defined split (for example, anything under 80 hours of dev work is an enhancement) or if it should remain "soft" |
| 14:12:38 | *** | bobmc (bobmc!n=gmccool@12.188.157.129) has joined #Opticks |
| 14:13:08 | tclarke | I'm in favor of keeping it soft |
| 14:13:15 | gmartin_cn | It is a gray area, but an enhancement (to me) adds capability to an existing feature, whereas a feature is new in and of itself. |
| 14:13:22 | gmartin_cn | But agreed, it can sometimes be a soft or gray area |
| 14:14:03 | dsulgrov | I agree with gmartin_cn... an enhancement enhances something that already exists |
| 14:14:09 | tclarke | I tend to agree but I think an additional heuristic is useful. if it adds all new functionality but is a very small effort, it can be an enhancement |
| 14:14:12 | kstreith | whatever criteria we use to separate bw/ enhancement and new feature needs to be something the submitter can use when entering the issue |
| 14:14:29 | rforehan | I don't think size of change should be a factor - the process flow should be the deciding factor. |
| 14:14:49 | tclarke | perhaps if the extra effort needed for the full feature workflow could take longer than the likely implementation, it can be an enhancement |
| 14:15:01 | dsulgrov | a user won't neccessarily know about process flow, though |
| 14:15:06 | tclarke | it's tough because the judgement needs to be make before the design |
| 14:15:09 | tclarke | but I think that often we can tell |
| 14:15:29 | tclarke | dsulgrov: correct, but it's fairly easy for us to reclassify when it is submitted |
| 14:15:39 | kstreith | i lean towards just having "new feature" |
| 14:15:46 | tclarke | it can be reclassified anytime but it's more difficult if there has been any design work done already |
| 14:15:53 | kstreith | and we just lighten the procedure |
| 14:15:57 | *** | plin (plin!i=0cbc9d81@gateway/web/ajax/mibbit.com/x-a21296d78cfd5751) has joined #opticks |
| 14:15:58 | kstreith | as it's executed |
| 14:16:22 | goffena | do the Ball testers or CMMI folks have a definition of enhancement vs new feature? |
| 14:16:39 | tclarke | for the late arrivals, please indicate that you are "here" so we can keep an accurate attendance |
| 14:16:57 | goffena | Might be useful to stay in line with their thinking |
| 14:16:58 | plin | here |
| 14:17:26 | kstreith | goffena: just tried googling, didn't see anything |
| 14:18:11 | rforehan | Would make creating new issue easy - user chooses bug or new feature. Then we can decide in triage if it needs extra review. |
| 14:18:25 | plin | there are definitions in jira |
| 14:18:57 | jtobe | here |
| 14:19:19 | kstreith | rforehan: i was suggesting we totally remove the enhancement type (only bug/new feature remain) |
| 14:19:26 | dsulgrov | but from a user's perspective, if I want to request a change in default behavior, that is neither a bug nor e new feature |
| 14:19:47 | rforehan | kstreith: I was agreeing with you. |
| 14:19:54 | tclarke | kstreith: I'm ok bringing this up again but do recall we discussed removal last meeting and unanimously decided to keep Enhancement |
| 14:19:59 | kstreith | rforehan: ok |
| 14:20:12 | dsulgrov | I think the current bug, enhancement, new feature is fine and makes sense to a user |
| 14:20:42 | tclarke | dsulgrov: I'm not so sure since it seems the developers are unclear about the distinction sometimes |
| 14:21:06 | dsulgrov | perhaps we could change enhancement to have the same workflow as new feature... |
| 14:21:17 | tclarke | but then there seems to be no point to having both |
| 14:21:18 | dsulgrov | and add additional transitions to the workflow |
| 14:21:50 | dsulgrov | by that logic, bug and enhancement should be identical |
| 14:21:52 | tclarke | to me at least, the main benefit to enhancement is the removal of the extra steps if they seem unnecessary for the scope of the change |
| 14:22:18 | tclarke | enhancement is new capability, feature is new capability, bug is a problem with existing capability |
| 14:22:23 | tclarke | that seems pretty clear to me |
| 14:22:27 | kstreith | tclarke: but the steps are accomplishing the same thing, it's just a difference in amount of rigor |
| 14:23:00 | tclarke | correct...the feature has the extra step of "do we understand what the reporter is requesting and what is the 10k foot estimate" |
| 14:23:14 | tclarke | the next step is "how would we design it and what is the 1k foot estimate" |
| 14:23:19 | tclarke | which is the common step |
| 14:23:38 | rforehan | Enhancement can just be new functionality without any new capaibility - e.g., change in display icon. |
| 14:23:55 | tclarke | I don't see the difference between "funcitonality" and "capability" |
| 14:24:08 | tclarke | they seem synonymous to me |
| 14:24:47 | tclarke | this discussion seems to be taking a while...I suggest we continue on the mailing list in the interest of time |
| 14:24:54 | tclarke | and move on to the net issue |
| 14:25:28 | kstreith | i agree |
| 14:25:44 | tclarke | ok...closing discussion for now...I'll post a summary to the mailing list and people can reply to that thread if they would like to continue |
| 14:25:47 | tclarke | next issue |
| 14:25:49 | tclarke | geocentric views |
| 14:26:13 | tclarke | one of the larger features slated for 4.3.x development right now is a common view coordinate system |
| 14:26:22 | tclarke | geocentric is a bit of a misnomer |
| 14:26:46 | tclarke | currently, the coordinate system for a view is pixel based and the 0,0 point is the 0,0 point in the primary raster layer |
| 14:27:29 | tclarke | geocoordinates are occasinally used but generally for display purposes...i.e. offsets and annotation locations are really pixel based but occasionally are converted from geo coords |
| 14:28:04 | tclarke | the basic idea of the new feature is to attach a coordinate system to the view and all layers will natively use that...layers/data elements can have their own coordinate systems |
| 14:28:16 | tclarke | and the locations are translated to the view system as necessary |
| 14:29:00 | tclarke | one possible implementation is to draw in OpenGL space using the native coordinates (currently, the 3-d coordinates in OpenGL are floating point versions that map to the pixels in the actual window) |
| 14:29:14 | tclarke | we want to hammer out some more of the detailed requirements |
| 14:29:44 | tclarke | for example: should the user be able to change the view's coordinate system or should it always default to the coordinate system of the "primary raster layer" when it is initialized |
| 14:29:58 | tclarke | discussion is open |
| 14:31:13 | jtobe | what options would the user have if they could change it? |
| 14:31:47 | tclarke | probably anything we knew how to translate to/from....we'd likely use proj4 for the projections so anything it knows about |
| 14:32:01 | dsulgrov | does view coordinate system = map projection? |
| 14:32:06 | rforehan | will the imagery be warped to fit into a rectangular coord system |
| 14:32:20 | tclarke | there's always be an option to use pixel based coords but anchor it to a view 0,0 and not the primary raster element's |
| 14:32:23 | kstreith | ok, just so everyone is aware, here's an article about datums |
| 14:32:30 | kstreith | http://www.colorado.edu/geography/gcraft/notes/datum/datum_f.html |
| 14:32:46 | tclarke | the warping may or may not be supported...that's an option |
| 14:32:49 | dsulgrov | tclarke: isn't that the same as using screen coords? |
| 14:32:56 | tclarke | not really |
| 14:33:01 | kstreith | the question is should datums be involved? |
| 14:33:11 | tclarke | right now, you can't really offset and stretch the primary..it won't work right |
| 14:33:34 | tclarke | if it's a view clamped pixel coordinate system, then it makes sense to allow primary raster offset and stretch |
| 14:33:56 | tclarke | kstreith: it's possible....do we forsee a need for different datums? |
| 14:34:20 | tclarke | if we used OpenGL coordinates which correspond to the view's system, it would be easy to do some warping |
| 14:34:24 | tclarke | anything affine |
| 14:34:37 | tclarke | we could support non-linear warping if needed but it would be trickier |
| 14:35:11 | jtobe | this would be a user setting I assume? does it make sense to have the setting and make "use primary raster layer" one of the options? |
| 14:35:36 | tclarke | there would be a default coordinate system which could be user settable |
| 14:35:53 | tclarke | I'd assume the deffault view system would be the view system of the first layer added |
| 14:36:13 | tclarke | but that layer's coordinate system needs to be defined...either by the plug-in which created it or using some default |
| 14:37:01 | rforehan | Would the georef plug-in for a RE be responsible for the coordinate conversion? |
| 14:37:31 | tclarke | not necessarily....it would need to map the RE's pixels to something else |
| 14:37:40 | tclarke | that something else would be the RE's coordinate system |
| 14:38:00 | tclarke | translations to other coordinate systems could happen in the core provided the two systems where know to the core |
| 14:39:03 | tclarke | here's the list supported by Proj4 |
| 14:39:04 | tclarke | http://www.remotesensing.org/geotiff/proj_list/ |
| 14:39:51 | tclarke | the coordinate systems used in opticks right now are: pixel, LatLon, MGRS, and UTM |
| 14:40:55 | tclarke | so the interesting bits needed seem to be: |
| 14:41:12 | tclarke | conversion from RE pixels to an appropriate coordinate (could be a 1-1 conversion) |
| 14:41:30 | tclarke | definition of those coordinates (assumed to be WGS84 in Opticks right now) |
| 14:41:49 | tclarke | how to convert those coordinates to other coordinates in the same or different projection |
| 14:42:22 | tclarke | what is the reference system (0 point, projection, coordinate system) |
| 14:42:51 | tclarke | how to project those points to a window (likely will be handled by OpenGL but the camera needs to be set up so it projects properly) |
| 14:42:55 | tclarke | . |
| 14:44:01 | tclarke | any other ideas? remember this is early design phase so there will be plenty of time to feedback on the design as it progresses but I'd like to start off in the correct direction |
| 14:44:43 | tclarke | ok, let's call this topic finished |
| 14:45:00 | tclarke | it's open discussion time, anything else that needs to be brought up? |
| 14:45:22 | tclarke | I'd like to point out that octave (and open source tool similar to matlab) is now embeddable |
| 14:45:32 | tclarke | which could leed to an interesting scripting plug-in for opticks' |
| 14:45:57 | tclarke | the down side is that octave is GPL so use or such a plug-in would make that installation of Opticks GPL and not LGPL |
| 14:46:09 | tclarke | but something like that could be placed into COAN |
| 14:46:14 | tclarke | . |
| 14:46:37 | tclarke | ok, last chance for topics |
| 14:46:55 | tclarke | ok, I'll post the meeting notes in the usual place and send an email to dev@opticks |
| 14:47:10 | tclarke | the next meeting is in two weeks...feel free to add to the agenda |