| User | Post |
|
1:25 am March 24, 2010
| Luke Maurits
| | Adelaide, Australia | |
| Admin
| posts 1483 | |
|
|
I am keen to get the proposal system for CLLARE up and running soon so that we can appeal to our very large number of new Reddit members for ideas.
How do people feel about the following:
For the proposal system in general (i.e. all projects), the basic system is this. A Call For Proposals must specify:
- A precise statement of proposal requirements, i.e. all proposed systems must achieve X, Y, Z, using A, B, C, not using L, M, N.
- A precise statement of "bonus" requirements, i.e. things that proposals don't have to achieve, but which would be very nice.
- A template for proposal submissions, making it clear what information a proposal needs to include (this will obviously be very proejct specific)
- A list of criteria which proposals will (in principle), be judged on the basis on.
- A day on which proposals must be complete by, after which voting will happen.
What do people think of this system?
For CLLARE, with regard to the proposal submission template, there is a draft in the Wiki here. What do people think of it?
|
Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.
|
|
|
7:09 am March 24, 2010
| brmj
| | Rochester, New York, United States | |
| Member | posts 402 | |
|
|
This looks basically good, but the bonus requirements and the list of chriteria proposals will be judged on are a little redundent. the bonus requirements would necesarilly be some of the same things that would be deciding factors if all the esentials were met in multiple proposals.
|
Main work groups: Propulsion (booster), Spacecraft Engineering, Computer Systems, Navigation and Guidance (software)
|
|
|
7:35 am March 24, 2010
| Luke Maurits
| | Adelaide, Australia | |
| Admin
| posts 1483 | |
|
|
brmj said:
This looks basically good, but the bonus requirements and the list of chriteria proposals will be judged on are a little redundent. the bonus requirements would necesarilly be some of the same things that would be deciding factors if all the esentials were met in multiple proposals.
I suppose these parts need some clarification. What I had in mind wouldn't necessarily be redundant.
With CLLARE I was thinking along these sorts of lines:
- Requirements: 1) Be able to land one person on the moon and return them to Earth safely. 2) Use a pre-existing (or likely to be finished soon) launch vehicle.
- Bonus Requirements: Be scalable down to lesser missions (circumlunar, earth orbtial, suborbital) in some meaningful sense (i.e. these sorts of missions should involve less hardware, a lower stack mass, etc).
- Judging criteria: Safety/redundancy (e.g. meaningful abort options at many points in the flight, in response to many potential failures), minimal dependence on the development of our own technology (e.g., on this particular metric ballutes are bad because we can't just buy one, the way we could probably buy a suitable parachute), etc.
Does this seem sensible?
|
Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.
|
|
|
6:35 am March 25, 2010
| Rocket-To-The-Moon
| | Altus, Oklahoma, USA | |
| Member | posts 685 | |
|
|
Just to clarify, are we talking about project proposals, or proposals for individual pieces of hardware.
|
Main Workgroups: Propulsion & Spacecraft Engineering
|
|
|
6:42 am March 25, 2010
| Luke Maurits
| | Adelaide, Australia | |
| Admin
| posts 1483 | |
|
|
I am talking about project level proposals. E.g., for CLLARE, choosing between the plan with the conical CM and open LL, the plan with the spherical CM and any other proposals people come up with. Proposals for individual pieces of hardware should be made through a much more lightweight system.
|
Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.
|
|
|
5:32 pm March 25, 2010
| heawill
| | Toronto, ON | |
| Member | posts 7 | |
|
|
I suspect it will become much clearer to us what's absolutely necessary in a proposal after we get a few, but I checked out the wiki sample and nothing stood out. On the note of proposals, though, do we have a system for receiving proposals? I mean, is there a proposal email or form or website? Or am I putting the cart in front of the horse? 
|
|
|
5:56 pm March 25, 2010
| Luke Maurits
| | Adelaide, Australia | |
| Admin
| posts 1483 | |
|
|
heawill said:
On the note of proposals, though, do we have a system for receiving proposals? I mean, is there a proposal email or form or website? Or am I putting the cart in front of the horse? 
We haven't really spoken about that much yet, since I guess the focus has just been on figuring out what we need in a proposal.
I think it should be sufficient to implement this in the Wiki. People can create a new page, use the CLLARE Proposal Template that is in the Wiki to initialise it, then fill out the details. We can have a centralised list of proposals on the Wiki somewhere. When people create a new proposal they can add it to the list.
We'll have to write up a brief set of instructions on this, e.g. a page naming scheme for proposals, how to use the template, etc., but it shouldn't be too hard.
I am keen to see this get done soon so we can start getting detailed investigation done on the proposals, especially now that we have another engineer in our ranks to help. If people are in general agreement that the currently proposed system is looking at least good enough to test out, then I can make all the Wiki updates today sometime. Once that's done we can make a blog post, link to it on Reddit, etc., and hopefully see if we can get some more ideas in addition to the current two we have worked out ourselves.
|
Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.
|
|
|
8:15 am April 4, 2010
| Luke Maurits
| | Adelaide, Australia | |
| Admin
| posts 1483 | |
|
|
To try to keep our momentum up, since nobody has voiced any objections to things as they have stood for a while, I have taken some further steps toward implementing the proposal system on the Wiki. There are now 3 proposal pages that have had work started on them. The names are just the first sensible sounding things I came up with, I am happy to see them changed if people feel strongly about it:
Links to all of the above are now present at the main CLLARE page, too.
It would be good to start soliciting both additional proposals and more work on these proposals from the community (with a blog post, Reddit cross post, etc, etc). Before we do this, though, we should probably set a deadline. Do people agree that two months should be adequate?
|
Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.
|
|
|
4:09 pm April 5, 2010
| Rocket-To-The-Moon
| | Altus, Oklahoma, USA | |
| Member | posts 685 | |
|
|
What are the exact criteria that we evaluate each proposal on? I know the goal is to send a single human to the moon and return them to Earth (alive). Beyond that is the next factor cost and nothing else?
|
Main Workgroups: Propulsion & Spacecraft Engineering
|
|
|
9:28 pm April 5, 2010
| Luke Maurits
| | Adelaide, Australia | |
| Admin
| posts 1483 | |
|
|
Rocket-To-The-Moon said:
What are the exact criteria that we evaluate each proposal on? I know the goal is to send a single human to the moon and return them to Earth (alive). Beyond that is the next factor cost and nothing else?
This is a good question, and I guess something we should be explicit about (even though we can't really enforce it – people will vote on what they want for their own reasons). I don't think it should be cost alone. Simplicity/reliability should be a big part of it. I would not want to endorse a proposal which was very cheap but which depended on lots of complicated things happening just right for success. Safety in general is probably a good factor to use. Maybe less important than these but still worth keeping in mind is adaptability. If a proposal's hardware stack can be used for multiple purposes (like the common lander base from the Apollo Lite proposal) before/after a manned landing, that should count in that proposal's favour.
Can anyone think of anything else?
|
Main CLLARE workgroups: Mission Planning, Navigation and Guidance. I do maths, physics, C, Python and Java.
|
|
|
6:57 am April 23, 2010
| Kurouma
| | |
| Member | posts 8 | |
|
|
I think for a good proposals and hardware/software ideas system in general, aside from CLLAIRE, for the members to use to get their ideas out and about in the community, there needs to be:
- Only one channel through which all proposals, everything in general, are submitted – from whole mission outlines to smaller subunit ideas
- Submitting member then gets to identify what discipline/subsection of the community this falls under, and includes all relevant info
- Then the community of that section get to view the list of proposals somehow – as part of the fora, for example
- Then the community get to discuss and offer modifications
But I wanna stress the idea that there needs to be some kind of standard form to fill out in order to propose any idea, rather than just making conversation in the fora. Because then everyone's on even ground and there's no ambiguity in what's in and what's out, and competing ideas can be compared objectively and having the structure will naturally develop well thought out ideas, rah rah rah…essentially a plus for organisation, and quality control.
Or have I overstepped the mark suggesting this?
Kurouma
|
|
|
1:18 pm April 23, 2010
| antinode
| | |
| Member | posts 64 | |
|
|
Kurouma, I've been theorizing how this organization could best run and I completely agree with your points. As of now I'm considering two separate proposal systems.
One would be for general project proposal form where anyone can suggest a new project idea. At this stage we're already over our heads with projects so this isn't really needed quite yet. This can already be done in the forums anyway.
The other proposal system is what this thread is about, and is something each individual project would use. This concept already exists in software development, in the form of issue/bug trackers. These provide an easy way to manage all types of issues including defects, patches, and feature proposals. These individual items support prioritization, categorization, status, and discussion. This already works well for software. There's no reason it couldn't be used for hardware as well. Something along the lines of what Luke suggested could be built in as a simple form.
|
|