Things I'm going to formalize in this topic will include the following (as I can solidify them in my mind):
1) Mission Statement
2) Overall Goal of the Project
3) Sub-Goals of the Project
4) Standards of the Project
5) Direction of the Project
6) Categorization of Those Involved
I just *know* that last one makes some people nervous, since is sounds suspiciously like stereotyping. It's more like assessing the strengths and complementing weaknesses with those strengths. It's what I did as a CEO, and now as the project admin I'm applying those same principles in the hopes that it wasn't me that was the problem with the theory. If it turns out to be, we can always change things.
Don't expect the above list to be in any particular order. As things develop and grow, some things may change, and I'm almost positive that clarity will come as more people get involved.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The aim of the Red Heron Enterprise Resource Planner is to create a free system that molds to the needs of the company, rather than forcing the company to conform to the software's way of doing things. Software should serve the needs of business, not the other way around.
We also have the secondary goal of helping to stimulate economies by increasing the availability of an enterprise-class system that is easy enough for the end user to use without ever having to pick up a manual, but with a manual that explains every facet of the software's operation so that there isn't any question. The manual, like the software, will be maintained on an open-source format (a wiki).
Our tertiary aims in support of these goals is to have a well-integrated team who can work through an open and democratic process for creating the software, and who share the goals above as the primary reasons they are with the project. Even if we don't speak the same language, the goal is very much the same. We also want to stimulate the belief that when you know what you have available, planning the ways to use those resources becomes much easier and more efficient.
Our initial marketing slogan for the pre-release (at least until the beta release) will be: "Freedom to choose is freedom to profit."
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Release 1 will be a completed package, and the first complete package. Release 2 will be a complete rewrite from the ground up, as will release 3, etc., until we have something that doesn't need a complete rework. Each full release should be a complete reworking of the software. We can keep code (just as we can import code from other FOSS projects) so long as we retain correct attributions and notes stating where we imported from.
Minor releases, such as the current 0.1 are stages in the evolution of the software. They might also be bugfixes. We should not have a leading zero on minor release numbers (e.g., 0.01) because that implies that there are more than 100 known bugs we need to fix. Well, unless there are that many bugs. I know it's counterintuitive for a lot of mathematicians, but after release 0.9 is 0.10 and then 0.11. The minor release number is not an actual decimal number, it's a means of version control.
Subrelease numbers are typically build numbers based on the minor subrelease. I fully expect to see things like 0.1.1950 if we're analyzing the code, because the code itself belongs to the project, though attribution remains with the coder. The benefit of this is that everyone should feel free to modify everyone else's code and improve it. That's the way Open Source is supposed to work. Subrelease numbers should be meaningful only to the people on the project; there's no real reason to include them in package information.
After the subrelease is a candidacy designation. There are four common designations here: Alpha (a), Beta (b), Release Candidate (RC), and an empty designation that implies a full release. We will utilize a hyphen between the minor release number and the candidacy designation for all releases that designate a candidacy designation.
So what's the difference between these?
Alpha means it's still being worked on. The current version (at the time of this writing) is alpha. We have barely a basic framework to put things onto, which will strengthen as we go.
Beta means we're testing the software for bugs by giving it to people to torture-test it and report back to us what's wrong. We fix the bugs, rinse, and repeat. Using this system, there should be no reason for "known bugs" in any full release.
Release Candidate means that we've fixed all the bugs, and are now fully engaged in torture-testing it ourselves in addition to going through the code and cleaning it up. We should, at this point, also have a complete manual, which we will need to have tested by someone who is a complete noob. We want the manual to give someone who doesn't know the difference between a mousepad and a digitizer tablet, so that they can then tell us where the manual is confusing, unclear, wrong, or could be worded better. The main activity on an RC release should be completion of the manual, and minor bugfixes. If we need to take it back to beta, then the next time it comes back it'll be RC2, etc., until we have a full release. Release candidates do occur on minor releases.
Once we have a full release, the designators on the end drop, and we're done. Red Heron ERP 1.0 will be complete. Then we'll get to work on 2.0 if we need to, otherwise we go for as many modules as possible for as many purposes as possible. I think the first module will be a CRM module.
Module numbers relate to the release that they were issued with. If we're on RHERP 3.0 and a module is version 1.54, then it was released with version 1.x and we might need to upgrade a few lines of code to make it 3.x instead. The exception is use of the word "for". If it's SuperCool Module 1.54 for RHERP 3.0 then that's fine. They can use whatever numbers they want, and we don't care.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
All standard image formats should be fine. I tend to save as PNG for now, but for smaller images use JPG since the compression is better. Quality should be over 70 for all images. The use of .gif files should be more for space savings than anything else, and also because they're easier for cross-browser functionality. PNG files are good for maintaining quality, but they should only be used for background images, and they should be relatively faded out. An occasional PNG banner should be fine.
Except for the favicon.ico file, BMP files should be avoided at all costs, though WBMP files should be fine for mobile access functions.
Other file formats should be avoided, since they're not standard for network access. As this changes, we should change with it, but for now please stay with the CURRENT standard.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Things I'm going to formalize in this topic will include the following (as I can solidify them in my mind):
1) Mission Statement
2) Overall Goal of the Project
3) Sub-Goals of the Project
4) Standards of the Project
5) Direction of the Project
6) Categorization of Those Involved
I just *know* that last one makes some people nervous, since is sounds suspiciously like stereotyping. It's more like assessing the strengths and complementing weaknesses with those strengths. It's what I did as a CEO, and now as the project admin I'm applying those same principles in the hopes that it wasn't me that was the problem with the theory. If it turns out to be, we can always change things.
Don't expect the above list to be in any particular order. As things develop and grow, some things may change, and I'm almost positive that clarity will come as more people get involved.
Mission Statement:
The aim of the Red Heron Enterprise Resource Planner is to create a free system that molds to the needs of the company, rather than forcing the company to conform to the software's way of doing things. Software should serve the needs of business, not the other way around.
We also have the secondary goal of helping to stimulate economies by increasing the availability of an enterprise-class system that is easy enough for the end user to use without ever having to pick up a manual, but with a manual that explains every facet of the software's operation so that there isn't any question. The manual, like the software, will be maintained on an open-source format (a wiki).
Our tertiary aims in support of these goals is to have a well-integrated team who can work through an open and democratic process for creating the software, and who share the goals above as the primary reasons they are with the project. Even if we don't speak the same language, the goal is very much the same. We also want to stimulate the belief that when you know what you have available, planning the ways to use those resources becomes much easier and more efficient.
Our initial marketing slogan for the pre-release (at least until the beta release) will be: "Freedom to choose is freedom to profit."
Standards of the Project: Release Numbers
We are on release 0.1.1-a
Release 1 will be a completed package, and the first complete package. Release 2 will be a complete rewrite from the ground up, as will release 3, etc., until we have something that doesn't need a complete rework. Each full release should be a complete reworking of the software. We can keep code (just as we can import code from other FOSS projects) so long as we retain correct attributions and notes stating where we imported from.
Minor releases, such as the current 0.1 are stages in the evolution of the software. They might also be bugfixes. We should not have a leading zero on minor release numbers (e.g., 0.01) because that implies that there are more than 100 known bugs we need to fix. Well, unless there are that many bugs. I know it's counterintuitive for a lot of mathematicians, but after release 0.9 is 0.10 and then 0.11. The minor release number is not an actual decimal number, it's a means of version control.
Subrelease numbers are typically build numbers based on the minor subrelease. I fully expect to see things like 0.1.1950 if we're analyzing the code, because the code itself belongs to the project, though attribution remains with the coder. The benefit of this is that everyone should feel free to modify everyone else's code and improve it. That's the way Open Source is supposed to work. Subrelease numbers should be meaningful only to the people on the project; there's no real reason to include them in package information.
After the subrelease is a candidacy designation. There are four common designations here: Alpha (a), Beta (b), Release Candidate (RC), and an empty designation that implies a full release. We will utilize a hyphen between the minor release number and the candidacy designation for all releases that designate a candidacy designation.
So what's the difference between these?
Alpha means it's still being worked on. The current version (at the time of this writing) is alpha. We have barely a basic framework to put things onto, which will strengthen as we go.
Beta means we're testing the software for bugs by giving it to people to torture-test it and report back to us what's wrong. We fix the bugs, rinse, and repeat. Using this system, there should be no reason for "known bugs" in any full release.
Release Candidate means that we've fixed all the bugs, and are now fully engaged in torture-testing it ourselves in addition to going through the code and cleaning it up. We should, at this point, also have a complete manual, which we will need to have tested by someone who is a complete noob. We want the manual to give someone who doesn't know the difference between a mousepad and a digitizer tablet, so that they can then tell us where the manual is confusing, unclear, wrong, or could be worded better. The main activity on an RC release should be completion of the manual, and minor bugfixes. If we need to take it back to beta, then the next time it comes back it'll be RC2, etc., until we have a full release. Release candidates do occur on minor releases.
Once we have a full release, the designators on the end drop, and we're done. Red Heron ERP 1.0 will be complete. Then we'll get to work on 2.0 if we need to, otherwise we go for as many modules as possible for as many purposes as possible. I think the first module will be a CRM module.
Module numbers relate to the release that they were issued with. If we're on RHERP 3.0 and a module is version 1.54, then it was released with version 1.x and we might need to upgrade a few lines of code to make it 3.x instead. The exception is use of the word "for". If it's SuperCool Module 1.54 for RHERP 3.0 then that's fine. They can use whatever numbers they want, and we don't care.
Standards of the Project: Images
All standard image formats should be fine. I tend to save as PNG for now, but for smaller images use JPG since the compression is better. Quality should be over 70 for all images. The use of .gif files should be more for space savings than anything else, and also because they're easier for cross-browser functionality. PNG files are good for maintaining quality, but they should only be used for background images, and they should be relatively faded out. An occasional PNG banner should be fine.
Except for the favicon.ico file, BMP files should be avoided at all costs, though WBMP files should be fine for mobile access functions.
Other file formats should be avoided, since they're not standard for network access. As this changes, we should change with it, but for now please stay with the CURRENT standard.