RE: [Ldsoss] Scout Tracking
I can appreciate all the fervor for a web-based app. However, 1) The church has said no websites. You can't get away with making the this is scouting and that is the church distinction, anymore. 2) It is a legal problem to start posting information about minor children to the Internet. That would have to be decided at Church HQ and not by the local units. They don't even allow information to be posted into Family Search about living people, they just insert a LIVING placeholder. Being involved with security professionally, I would not give my consent. This is a huge pitfall -- despite good intentions -- it would be wise not to fall into it. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Hanks Sent: Tuesday, June 06, 2006 9:04 AM To: LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking On Tue, 6 Jun 2006, Tom Welch wrote: Web-based would be great, but with the church's policy on non-official websites, where does that put the local unit that would want to install and use such a web-based app? -- Dan ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Scout Tracking
However, the offline portion of MIS is offline. The online portion is fairly well secure. I don't trust my local scoutmaster or (sorry) the OSS community to make that assertion. PHP is about as secure as IE on a bad day... The distinction here is that MIS does not have personal information about likes, hobbies, awards, projects, etc. An online scouting tracking program would have more similarities with myspace.com than with the MIS. That's a huge distinction. In order to begin to think about an online database/app, you would be required to allow parents to opt out. As soon as one parent opted out, the online database would be more work for the Scoutmaster than it would be worth and they'd stop using it. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manfred Riem Sent: Tuesday, June 06, 2006 10:42 AM To: 'LDS Open Source Software' Subject: RE: [Ldsoss] Scout Tracking Hi Gary, Actually I think without wanting to start a legal debate about it this would be covered by you as a parent allowing your kids to be entered in the MIS already. Manfred. ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Web based is definitely the way to go. I have been mulling over doing something like this for some time. I'd be willing to help as time permits. --Richard On 6 Jun 2006 at 8:42, Tom Welch wrote: Slide wrote: What would be great is if you could also have a plug-in type system for working with the various religious awards as well (Duty to God for LDS) which would then allow other Scouting groups to take advantage of it without tying it to just LDS Scouting. Yes, DTG is on the map to integrate into this program. The thoughts were to create some kind of a web based application so that parents, scout leaders and boys can all work together. -- Tom Welch [EMAIL PROTECTED] (801) 240-1609 (858) 829-4614 - Cell - - NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. - - ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
re: RE: [Ldsoss] Scout Tracking
I would agree with both your concerns Steven, accept that, after reading the entire email trail from yesterday, this appears to be a project initiated by Church HQ and not some random person on the listserve. The church has said no unofficial websites - this to me would be an official website. GR Steven H. McCown [EMAIL PROTECTED] wrote: I can appreciate all the fervor for a web-based app. However, 1) The church has said no websites. You can't get away with making the this is scouting and that is the church distinction, anymore. 2) It is a legal problem to start posting information about minor children to the Internet. That would have to be decided at Church HQ and not by the local units. They don't even allow information to be posted into Family Search about living people, they just insert a LIVING placeholder. Being involved with security professionally, I would not give my consent. This is a huge pitfall -- despite good intentions -- it would be wise not to fall into it. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Hanks Sent: Tuesday, June 06, 2006 9:04 AM To: LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking On Tue, 6 Jun 2006, Tom Welch wrote: Web-based would be great, but with the church's policy on non-official websites, where does that put the local unit that would want to install and use such a web-based app? -- Dan ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss -- ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Scout Tracking
A scout program would be a great idea. Basing it using a web interface is also a great idea. Hopefully the program would also be setup to track the awards the adults need to be working on , their training, etc. As I understand the Church's position it is there are to be no web sites other than lds.org representing the Church. This does not mean using http://127.0.0.1/scout_tracking_tool is forbidden. The ability to connect remotely is not limited to web based applications - the windows desktop, X, KDE ,gnome, MacOSX, etc can all be connected to remotely - if the network and machine are configured to permit it. Web based applications - when written and carefully managed are neither less nor more secure than desktop programs. The web interface is simply a different api set than the various desktops that are available. There are many desktop programs which when carefully examined are not secure. The security requirement must be written with security as part of the program foundation rather than as some assumption based on other elements providing the security. I would love to see a web based open source scout/YM/YW application program. If the day ever comes where remote connections to Church applications are permitted it will be a great day. Doing a http://www.lds.org/myward/mls/ymyw_tracking would be excellent. In the interm being able to do a http://127.0.0.1/mls/ymyw_tracking would be excellent compared to the resources available today. Another way could be to ssh to a site , then run a X based browser such as konqueror or mozilla and then http://lds.org/mls/ymyw_tracking. The site could be ssh -X [EMAIL PROTECTED] . The requirements to keep all mls/youth/??? data off the internet would be meet due to ssh. The myaccount would be manageable - simply check your recommend - there are 2 numbers which could be used to control access for each member. Releasing the program as open source would not cause a security breach since access to the program nor the data the program would use would not be available without the required ssh account. The program would still be web based as access to anyone wishing to use it stand alone - such as the jayees sponsoring the scout troop I was a member of many years ago. They would simply setup a private LOCAL server and access it as http://127.0.0.1/scout/_tracking_tool . THe data 127.0.0.1 remains behind the firewall no data should leak and the only data in the program is what is entered locally. have a great day oscar The point is to strengthen the testimony of those involved in the various programs. -- Original message -- From: Steven H. McCown [EMAIL PROTECTED] I can appreciate all the fervor for a web-based app. However, 1) The church has said no websites. You can't get away with making the this is scouting and that is the church distinction, anymore. 2) It is a legal problem to start posting information about minor children to the Internet. That would have to be decided at Church HQ and not by the local units. They don't even allow information to be posted into Family Search about living people, they just insert a LIVING placeholder. Being involved with security professionally, I would not give my consent. This is a huge pitfall -- despite good intentions -- it would be wise not to fall into it. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Hanks Sent: Tuesday, June 06, 2006 9:04 AM To: LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking On Tue, 6 Jun 2006, Tom Welch wrote: Web-based would be great, but with the church's policy on non-official websites, where does that put the local unit that would want to install and use such a web-based app? -- Dan ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Scout Tracking
Hi Tom, You can only get that list if all the members agree to have it on there. Each member can elect to be removed from the listing. Manfred Riem [EMAIL PROTECTED] http://www.manorrock.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Welch Sent: Wednesday, June 07, 2006 7:29 AM To: LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking If the Church were to host the site, would that alleviate your concerns? Currently you can get a ward listing of all members in the ward, their address and phone numbers from the ward unit website. This would not be much different. Tom Steven H. McCown wrote: I can appreciate all the fervor for a web-based app. However, 1) The church has said no websites. You can't get away with making the this is scouting and that is the church distinction, anymore. 2) It is a legal problem to start posting information about minor children to the Internet. That would have to be decided at Church HQ and not by the local units. They don't even allow information to be posted into Family Search about living people, they just insert a LIVING placeholder. Being involved with security professionally, I would not give my consent. This is a huge pitfall -- despite good intentions -- it would be wise not to fall into it. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Hanks Sent: Tuesday, June 06, 2006 9:04 AM To: LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking On Tue, 6 Jun 2006, Tom Welch wrote: Web-based would be great, but with the church's policy on non-official websites, where does that put the local unit that would want to install and use such a web-based app? -- Dan ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss -- Tom Welch [EMAIL PROTECTED] (801) 240-1609 (858) 829-4614 - Cell -- NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -- ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
OK, so that would have to be a requirement of this software as well. Opt-out of being listed. I'm just throwing out ideas. There is nothing to say that we can't develop an application that can be both web based and stand alone. We are in the brainstorming mode here. To Manfred Riem wrote: Hi Tom, You can only get that list if all the members agree to have it on there. Each member can elect to be removed from the listing. Manfred Riem [EMAIL PROTECTED] http://www.manorrock.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tom Welch Sent: Wednesday, June 07, 2006 7:29 AM To: LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking If the Church were to host the site, would that alleviate your concerns? Currently you can get a ward listing of all members in the ward, their address and phone numbers from the ward unit website. This would not be much different. Tom Steven H. McCown wrote: I can appreciate all the fervor for a web-based app. However, 1) The church has said no websites. You can't get away with making the "this is scouting and that is the church" distinction, anymore. 2) It is a legal problem to start posting information about minor children to the Internet. That would have to be decided at Church HQ and not by the local units. They don't even allow information to be posted into Family Search about living people, they just insert a "LIVING" placeholder. Being involved with security professionally, I would not give my consent. This is a huge pitfall -- despite good intentions -- it would be wise not to fall into it. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dan Hanks Sent: Tuesday, June 06, 2006 9:04 AM To: LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking On Tue, 6 Jun 2006, Tom Welch wrote: Web-based would be great, but with the church's policy on non-official websites, where does that put the local unit that would want to install and use such a web-based app? -- Dan ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss -- Tom Welch [EMAIL PROTECTED] (801) 240-1609 (858) 829-4614 - Cell -- NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -- ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss -- Tom Welch [EMAIL PROTECTED] (801) 240-1609 (858) 829-4614 - Cell --
Re: [Ldsoss] Scout Tracking
There are fundamentally two architectures. Standalone and online. Any discussion we can have about the merits and demerits of both have been repeated ad-nausea for every application since the birth of the Internet. If we try to boil the ocean on the first pass, the project is doomed from the beginning. Can you image what would have happened if Linus Torvalds had tried to release Red Hat as a replacement to Minux? Get something that works well and that installs well on a local machine. Refactor it so that the business tier, the presentation tier and the model tier are distinct. Drop it on a disconnected appserver and add an additional presentation tier to prove that the refactoring is sufficient. It won't be, so count on additional refactoring. Now you have a functional solution that is worth debating security/privacy/convience issues about taking online. The worst case scenario is, you have a solution that works for you, and that others can install and that will work for them. Pushing security concerns into the application logic itself, is IMHO, absolutely poor design!!! Security and security policies are cross-cutting concerns that should be done declaratively in a security policy manager, or at worst, in the appserver. As a ward member, do you really want to have to log in and validate against every piece of functionality restricted to members on the church website. Ex: Once I log in once, switching to the ward webmaster mode doesn't require a new authentication. Why? Because the authentication is done at the middleware layer, not the individual application layer. -- A. Rick Anderson ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Scout Tracking
Hi there, I think we all know this. The problem is really how the Church wants us to proceed in this. If we want an 'open-source' project to be used within the boundaries the Church has to abide by we need to know those boundaries. I for one know there are a lot of boundaries based on the various countries the Church has a presence in. So to just dismiss it as something we shouldn't be discussing is like sticking your head in the sand. The structure of the security is not being discussed here, but the boundaries. BTW Linus didn't create Redhat it is just one instance of a Linux distro. Kind regards, Manfred Riem [EMAIL PROTECTED] http://www.manorrock.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of A. Rick Anderson Sent: Wednesday, June 07, 2006 10:23 AM To: LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking There are fundamentally two architectures. Standalone and online. Any discussion we can have about the merits and demerits of both have been repeated ad-nausea for every application since the birth of the Internet. If we try to boil the ocean on the first pass, the project is doomed from the beginning. Can you image what would have happened if Linus Torvalds had tried to release Red Hat as a replacement to Minux? Get something that works well and that installs well on a local machine. Refactor it so that the business tier, the presentation tier and the model tier are distinct. Drop it on a disconnected appserver and add an additional presentation tier to prove that the refactoring is sufficient. It won't be, so count on additional refactoring. Now you have a functional solution that is worth debating security/privacy/convience issues about taking online. The worst case scenario is, you have a solution that works for you, and that others can install and that will work for them. Pushing security concerns into the application logic itself, is IMHO, absolutely poor design!!! Security and security policies are cross-cutting concerns that should be done declaratively in a security policy manager, or at worst, in the appserver. As a ward member, do you really want to have to log in and validate against every piece of functionality restricted to members on the church website. Ex: Once I log in once, switching to the ward webmaster mode doesn't require a new authentication. Why? Because the authentication is done at the middleware layer, not the individual application layer. -- A. Rick Anderson ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Steven H. McCown wrote: 2) It is a legal problem to start posting information about minor children to the Internet. That would have to be decided at Church HQ and not by the local units. They don't even allow information to be posted into Family Search about living people, they just insert a LIVING placeholder. Being involved with security professionally, I would not give my consent. This is a huge pitfall -- despite good intentions -- it would be wise not to fall into it. As a father of seven and the former owner of an internet security company I don't view this as an huge problem: (1) I currently use etrailtoeagle.com to track the D2G progress of our YM. However, I don't use the YM's full name but just their first names or nickname. e.g. Johnny, Billy, Joey. There is no reason to use the full name. (2) About the only personal information you would be posting to a website is the child's birthday. Something that is public record anyway. (3) I am more worried about other websites with my children's information. For example: In Texas, most of the public schools have a lot more information about our children on their websites. I log in to the school web site to see my children's grades and attendance records. In addition, the school website has my child's address, parent's names, etc. (4) For the ultra security minded parents you simply allow them to opt out and track their own kid's progress them self. Of course, this is something that every YM's leaders would hope for. That is, the parent, who is ultimately responsible, be fully involved in their child's life. If this were the case for all our YM and their parents then we wouldn't have a need for tracking software or this discussion. Regards, -stacey. ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking - getting back on the trail
I've been reading this thread with some interest to see where it's going. Right now, it appears that the discussion is being dragged down a series of familiar self-inflicted rat holes. What would be most helpful to getting something productive, Tom, and others from HQ, is to offer, at a minimum, a rough design spec and/or set of sys req, to set the stage. If this is purely a conceptual exercise, then someone from HQ needs to lead the discussion, starting with a set of business requirements, and fleshing things out from there - AND not letting the discussion tail off into the weeds. Many of the people on this list are programmers first, designers second, if at all. They can give you elegant and clever solutions, but those solutions have no meaning without a framework to hang them on. Otherwise you will get the wounded duck, spiraling into the pond exercise from what was a good starting point. ...Paul Bryan Murdock wrote: On 6/7/06, Tom Welch [EMAIL PROTECTED] wrote: OK, so that would have to be a requirement of this software as well. Opt-out of being listed. Opt-out of having what listed for whom? We are still a long way off of even answering those questions. Others have given great responses to these premature security concerns, so I'll just say, amen, to them and leave it at that. Bryan ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking - getting back on the trail
Before we get to use-cases, lets start at the bottom: 1. Define the problem: ie: There is a need to track scouts and their information 2. From that, branch out into more detail with regard to business process. ie: I need to track scouts with in my district, Of the scouts in my district, the following information about their activities/awards/rank are important... 3. These constitute constraints and rules surrounding how you are handling the problem in a manual fashion. 4. Identify the data elements (not int, char, unsigned, but name, rank, troop, etc.) that are needed and necessary to address the problem and apply the rules. Now you can build specific use cases around the business processes you've identified, and from there dive into as much detail pain as you are willing to handle. The key is simplicity...Many simple rules and cases are much easier to map out and automate, than small sets of convoluted and incomplete rules and sets. Once you can walk someone end to end through the process of tracking the scouts, and there are no holes in either procedures or data elements, then we start with the technical design and framework, plus the user interface - no prototype yet... That comes after design proof.. In the meantime, someone from HQ should take the lead and manage the output from the group into a cohesive set of documentation from which the design will be derived. I never start coding anything until I know exactly what I need to do - no surprises that way, and no Microsoft bend it to fit, paint it match development. A. Rick Anderson wrote: Paul Penrod wrote: If this is purely a conceptual exercise, then someone from HQ needs to lead the discussion, starting with a set of business requirements, and fleshing things out from there - AND not letting the discussion tail off into the weeds. Many of the people on this list are programmers first, designers second, if at all. They can give you elegant and clever solutions, but those solutions have no meaning without a framework to hang them on. Otherwise you will get the wounded duck, spiraling into the pond exercise from what was a good starting point. As one who has been shooting at the duck grin, this is an excellent point! Would it make sense for this group to write up some use-cases/scenarios or simple stories as a means of driving out the requirements? That way, people could define the feature or issue that is of a concern to them in a use-case or story. ex: write-up a use-case for a parent who choses to opt-out, or a story of a data-voyeur trying to access someone else's information (whatever that may be), or of a district leader trying to validate the merit badges for an Eagle Scout candidate. All those who want to contribute could write up the stories, the actual folks who want to code the solution decide which ones they care about and want to do first and you have the beginnings of a set of functional requirements. Non-functional requirements can be driven out the same way, but most programmers don't want to think of those :-) ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking - getting back on the trail
We're in violent agreement! I do several iterations on a Use-Case, adding detail and information as I drill down. What you are calling a Business Process, I'd capture on the second iteration of use-cases as a business level use-case. See Writing Effective Use Cases by Alistar Cockburn. He recommends 5 abstraction levels for use-cases. The steps of a high level use-case become full-blown use-cases themselves, but at a lower level of abstraction. The alternative paths through a use-case constitute use-case scenarios. In a simple domain like this, I'd keep the business rules in the use-case just to reduce the number of documents to manage. Then, you define wire-frames or page mockup to capture the essence of the user-interaction. Based on the business-level use-cases you create a Screen-Flow showing the navigation path between the diagrams. Now you instantiate the use-case scenarios with specific data values and you end up with test-cases that you can validate before you even touch design. Make sure that you have a test-case that validates every business rule. The combination of these test-cases constitute an acceptance test. Before you even consider technology, you have defined the success criteria and there are no surprises to either the customer or the developer. Paul Penrod wrote: Before we get to use-cases, lets start at the bottom: 1. Define the problem: ie: There is a need to track scouts and their information 2. From that, branch out into more detail with regard to business process. ie: I need to track scouts with in my district, Of the scouts in my district, the following information about their activities/awards/rank are important... 3. These constitute constraints and rules surrounding how you are handling the problem in a manual fashion. 4. Identify the data elements (not int, char, unsigned, but name, rank, troop, etc.) that are needed and necessary to address the problem and apply the rules. Now you can build specific use cases around the business processes you've identified, and from there dive into as much detail pain as you are willing to handle. The key is simplicity...Many simple rules and cases are much easier to map out and automate, than small sets of convoluted and incomplete rules and sets. Once you can walk someone end to end through the process of tracking the scouts, and there are no holes in either procedures or data elements, then we start with the technical design and framework, plus the user interface - no prototype yet... That comes after design proof.. In the meantime, someone from HQ should take the lead and manage the output from the group into a cohesive set of documentation from which the design will be derived. I never start coding anything until I know exactly what I need to do - no surprises that way, and no Microsoft bend it to fit, paint it match development. A. Rick Anderson wrote: Paul Penrod wrote: If this is purely a conceptual exercise, then someone from HQ needs to lead the discussion, starting with a set of business requirements, and fleshing things out from there - AND not letting the discussion tail off into the weeds. Many of the people on this list are programmers first, designers second, if at all. They can give you elegant and clever solutions, but those solutions have no meaning without a framework to hang them on. Otherwise you will get the wounded duck, spiraling into the pond exercise from what was a good starting point. As one who has been shooting at the duck grin, this is an excellent point! Would it make sense for this group to write up some use-cases/scenarios or simple stories as a means of driving out the requirements? That way, people could define the feature or issue that is of a concern to them in a use-case or story. ex: write-up a use-case for a parent who choses to opt-out, or a story of a data-voyeur trying to access someone else's information (whatever that may be), or of a district leader trying to validate the merit badges for an Eagle Scout candidate. All those who want to contribute could write up the stories, the actual folks who want to code the solution decide which ones they care about and want to do first and you have the beginnings of a set of functional requirements. Non-functional requirements can be driven out the same way, but most programmers don't want to think of those :-) ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss -- A. Rick Anderson ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
On Wed, Jun 07, 2006 at 02:12:08PM -0400, A. Rick Anderson wrote: My point was that if Linus had attempted to implement all of the features added to the kernel over the last 15 years in the first iteration, Linux, as we know and love would have never have happened. Reminds me of the invention of calculus independently by Newton and Leibnitz. If either (regardless that both Newton and Leibnitz stand out among the world's recognized most intelligent people) were required to begin with Weirstrauss', and Riemann's, etc. formal statutes and methods of proof that we have today calculus would never have been invented. Justin ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
On Tue, Jun 06, 2006 at 07:34:23AM -0600, Tom Welch wrote: I used TroopMaster in the past and it did not require me to purchase a new license each year. However that was about 3 years ago and they may have changed their pricing plan. The biggest problem that I had with TroopMaster was that it is not easy to share with the next scout master that comes into the calling. At the Church we are looking at sponsoring an open source project around scouting. Any interested people that would like to work on such a program? I'm admittedly not very well informed about the requirements of the boy scouts program, but I'm curious about this: if the church sponsored an open-source project around scouting, would it be possible to set it up in such a way that it could be easily adjusted to: A) Duty to God (which i also know very little about) B) Young Women's Personal Progress the personal progress program involves fulfilling a number of goals in a variety of categories, and then some larger goals at the end... It seems that if this is going to be an official Church-sanctioned project, it would be ideal to make it expandable to tracking those tasks as well... ~Erin -- http://www.tuxgirl.com signature.asc Description: Digital signature ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
