Rocketry Book Online?

[manixFan]

Who'e going to moderate the glue thread? Not a job I'd want or envy!

Seriously, the first order might be to come up with an organizational scheme. Is it by power range? Do you have a model rocket, mid-power, and high-power construction section? Or is it by material types? Estes style kits, LOC style, fiberglass, carbon fiber? How is it indexed and searched? I worked on a big project years ago that failed because about halfway through it became obvious that the organizational scheme used to classify the data was insufficient and the amount of time it would take to reclassify everything was basically the same as starting over. There was no way it was going to make deadline or budget.

Having said that, it would be great to have an online resource of practical knowledge. Like a page for each type of tracker or altimeter that listed pros/cons, tips and tricks. Folks could use it as both a buying guide and to review for information on best practices. Same with a glue page - a quick description of each of the major adhesives that are typically used and their pros/cons, tips and tricks. Or motor issues, etc. For example there are threads here I have either bookmarked or turned into PDFs because the information has 'persistent usefulness'. But it is very hard to find if you don't already know about it. So a quick and easy way to find information should be a driving principal.

Just my thoughts on it,


Tony

(one example is a thread that describes how to take the log file from a Featherweight tracker and get it into Google Earth. Until that's written into the FIP software, that's a page a lot of folks would find very useful. There are many examples like that.)

 

[Ronz Rocketz]

This sounds like the start of a religion. How long until we have the 2nd Book of the TRF and the 3rd Book and the 4th Book? Eventually, clubs will be divided into which book one believes in.

 

[cwbullet]

That points out one of the risks of this kind of project that I have no idea how to deal with: if we build something online, it may eventually disappear or rot away even though it's valuable. How do we keep something like this alive and relevant so it can still be used 10 or 20 years from now?

That is easy. Nothing is forever. We have to continue to grow the base. This can't be a one-man operation.

 

[Joshua F Thomas]

Something like this might work:
https://www.dokuwiki.org
Or

Wordpress.

No. Not wordpress. Not wordpress *ever*.

 

[Joshua F Thomas]

That points out one of the risks of this kind of project that I have no idea how to deal with: if we build something online, it may eventually disappear or rot away even though it's valuable. How do we keep something like this alive and relevant so it can still be used 10 or 20 years from now?

I think you've just described a thing called a 'book'.

 

[cwbullet]

No. Not wordpress. Not wordpress *ever*.

Your suggestion?

 

[Jeff Lassahn]

We had ‘Rocketry Online’s INFOcentral’ several years back. I think it died around 2005. Just what ya’ll are talking about. You can find it on the Wayback machine.
https://web.archive.org/web/19990508224457/https://www.info-central.org/infocentral.shtml

It makes me sad to think we're talking about starting over recreating something that has been lost.
Who worked on INFOcentral? Why did it die? Is it worth tracking down the old content and resurrecting some of it?

 

[rocketlabdelta]

It makes me sad to think we're talking about starting over recreating something that has been lost.
Who worked on INFOcentral? Why did it die? Is it worth tracking down the old content and resurrecting some of it?

You know, I was thinking the same thing so I pulled all of the files for info-central.org out of archive.org and started cleaning them up.
It's rough around the edges and some of the pictures are missing but it shouldn't be too bad. There's less than 200 pages.

The content is up here:
https://info-central.rocketlabdelta.com/
Source is available on GitHub:
https://github.com/rocketlabdelta/info-centralEdits and pull requests are welcome.

From looking at the files it looks like the site was being maintained by Darrell Mobley who passed away in 2011.

 

[Sooner Boomer]

I support this effort. Let me know what I can do to help.

Two ideas I would like you to consider: samizdat, and copy-lefting.

Samizdat is a Russian term meaning "self-publishing" (originating from state-banned literature). This means, essentially, if you want a copy of the book I write, *you* print it out.

Copy-lefting is an idea of fairly recent origin, usually relating to a computer program, but can include written materials and photographs. The idea is that the author still retains the protections involved in the conventional copyright system, but allows free distribution and modification (with attributes). The copyleft is maintained in derrivative works. This means if Bob copylefts a work, George can use and modify the work, free of charge, but if George modifies and re-distributes the work, *this* work is also copylefted. Anyone is free to use the original or further derived work for non-commercial use (without prior approval). So if we all contribute ao a copylefted work, Zoom! rocketry cannot then turn around and sell the work for a profit. In theory, they *could* sell it for the cost of production (printing, brning a CD, etc.), but again, samizdat.

Lastly, I see each section broken down into a factual portion, and a discussion portion. The factual section would be just that. For example in a glue thread, the factual section would describe the chemistry and basic uses of different types of glue, perhaps describing the advantages and disadvantages of each type of chemistry. The discussion portion could give anecdotal evidence of why one is better than the other, and could serve as a modifier for the factual section.

 

[rocketlabdelta]

Copy-lefting is an idea of fairly recent origin, usually relating to a computer program, but can include written materials and photographs.

There are lots of licences to choose from. I release my rocket-related work under a Creative Commons Attribution license. There is also a copy-left flavor of that license: Creative Commons Attribution-ShareAlike

The Creative Commons family of licences are a good fit for writing and publications; many of the Open Source licences are designed for software.

 

[neil_w]

I would tend to favor Creative Commons licensing as well.

 

[JohnCoker]

There used to be a web site that collected articles and was more like a periodical (RocketryOnline.com) so it's definitely a good idea. These sorts of things are generally hard to maintain because they are so broad that they are a full time job. (Darrell Mobley ran a magazine and ROL was the Internet half of that.)

I keep the articles I write online, so if someone wants to start such a portal, they're welcome to link to any of my work: jcrocket.com/howto.shtml

 

[DaHabes]

That's a pretty good start. I agree that a knowledge base is the right model for this.

I'm uncertain of the notion of this new thing being "connected" to TRF, vs. an independent rocket wiki. I know Chuck proposed it and he is a Mod here but I admit I had been assuming the latter. If it's not managed or "owned" in any way by the TRF folks, or if they're not providing resources, I'm not sure why it should be so connected. That said, SSO with TRF could be nice.

I think a separate entity from TRF is preferable just as Thrustcurve is a separate entity. Notices go up on TRF when updates are made to Thrustcurve, same would apply to a wiki. TRF is a forum for interaction and communication; a wiki is a resource maintained by the knowledgeable for the benefit of all.

 

[DaHabes]

That points out one of the risks of this kind of project that I have no idea how to deal with: if we build something online, it may eventually disappear or rot away even though it's valuable. How do we keep something like this alive and relevant so it can still be used 10 or 20 years from now?

How does Wikipedia maintain viability? That's a general model to emulate. If this is really going to be viable, it would need a basic organizational structure, a board, defined roles (like moderators), basic rules for maintaining the structure and content. It would also need some minimal funding for web hosting, etc. Without structure it would 1) take forever to get off the ground, 2) may never get to critical mass and 3) eventually die a slow death. If you read L&DRS, think about what it took to get TRA up/running and mature. That's the effort required. The other question is can and should there be an affiliation with NAR/TRA/CAR? If nothing else, using those associations as a conduit to request member participation would likely allow for refresh of participants over time. It's also in their best interest to have a supported and canonical knowledge repository for the good of the hobby. Done well, this is not an effort that can be done ad hoc.

 

[JohnCoker]

Most hobby resources, like businesses, are a labor of love and can't be expected to survive their creator. A successful project long-term requires a group of active contributors so that as the initiators lose interest, it can continue.

ROL was Darrel Mobley and didn't long survive the demise of his rocketry magazine. As was remarked in another post on Gorilla Rocket Motors, the hobby is too small to sustain many vendors. The NAR and TRA magazines are loss-leaders to generate support for the hobby. There isn't enough money to support an independent publication.

For ThrustCurve.org, I have made the code open source so someone else can take over at some point. However since it costs money and time to maintain such a site, it's unlikely that it will outlive me. (I have a hard enough time getting people to share the data files they create, which costs nothing but 30s of time.)

 

[rocketlabdelta]

Most hobby resources, like businesses, are a labor of love and can't be expected to survive their creator. A successful project long-term requires a group of active contributors so that as the initiators lose interest, it can continue.

I think this is a key point. As I've been pouring over the content from Info Central I've come to appreciate just how much work it takes to build and sustain something like this. A good editor has to encourage, solicit, and massage contributions to a body of work.

I spent several years working with digital libraries and archives. There isn't a clear way of building data and software that will live on in perpetuity. The best we can do now is to move and migrate data as technologies change but that takes time and, frequently, specialized skills.

There are ways to minimize and defer the costs of web services but there are still basic things, like paying for a domain name, that are required for long-term operation. (There are some things like IPFS that might change that, but they aren't mainstream.) Once a domain name expires, all links to the content break and the service ceases to be discoverable.

To have a web service outlive it's founder there would need to be a succession plan in place and possibly a 501c3 that holds key assets.

Thrustcurve.org continues to exist solely because of @JohnCoker's dedication.

 

[Jeff Lassahn]

I think I just figured something out...
I've been noticing for a while that there's a much richer, more complete collection of rocketry stuff from the '60s and '70s available than there is from the '90s. If I want old technical reports, or books, or plans for old rocket designs, they're all available because somebody saved a copy.

I've been assuming some of this was because people from the age of print save stuff, and people from the age of the internet let things evaporate.

Now I think that's not right. It's more about things that are finite and finished vs things that are malleable. If I find an article online that's useful (particularly if it's in a self-contained format like PDF) I'm likely to download a copy and keep it. I don't do the same thing with wiki pages or forum posts. So wikis and forums and stuff won't outlive the active efforts of the people running the service, but self-contained documents live as long as someone can be found who kept a copy.

I guess as authors we have a choice: do we want create that are fluid and up-to-date, or do we create things that are permanent? Which one you want controls what kind of tools you should use.

 

[cwbullet]

I started this weekend. I have a domain name. Now, ask you what software to base it on? I would prefer an open-source, off-the-shelf product.

 

[heada]

https://en.wikipedia.org/wiki/MediaWiki

 

[hartlch]

Now I think that's not right. It's more about things that are finite and finished vs things that are malleable. If I find an article online that's useful (particularly if it's in a self-contained format like PDF) I'm likely to download a copy and keep it. I don't do the same thing with wiki pages or forum posts. So wikis and forums and stuff won't outlive the active efforts of the people running the service, but self-contained documents live as long as someone can be found who kept a copy.

I think it has a lot to do with the media that the information is stored on. Up until say the early 80's the majority of information was in hardcopy form - catalogs, magazines, technical reports, etc. - all on paper of some form. It is pretty easy to stash a copy of something on a shelf or in a box and when you need (or rediscover) it, you can just read it. As all that information started being stored and distributed in digital form, it became a victim of technological evolution. Either the formats became obsolete, or the physical storage medium became outdated. Even if the stuff was in a plain text file, maybe it was "archived" on one of the many disk or tape formats that have long since been replaced by something better. This isn't a new problem, there is a ton of scientific data from the early space probes that is no longer accessible in part due to this sort of problem.

 

[neil_w]

https://en.wikipedia.org/wiki/MediaWiki

MediaWiki is nice but does not really do hierarchy well, more of a giant flat organization. I think this project would benefit greatly from clear, visible, easy to navigate hierarchy.

The best one I know of at the moment is XWiki: https://www.xwiki.org/xwiki/bin/view/Main/WebHome

 

[heada]

MediaWiki is nice but does not really do hierarchy well, more of a giant flat organization. I think this project would benefit greatly from clear, visible, easy to navigate hierarchy.

The best one I know of at the moment is XWiki: https://www.xwiki.org/xwiki/bin/view/Main/WebHome

I envisioned something like a large knowledge base along the lines of wikipedia so hierarchy isn't a major consideration. I agree it doesn't do hierarchy well and if that's the end goal then another solution would be better.

 

[neil_w]

I envisioned something like a large knowledge base along the lines of wikipedia so hierarchy isn't a major consideration. I agree it doesn't do hierarchy well and if that's the end goal then another solution would be better.

Well, I was imagining, for instance, a section on Techniques, and possibly a subsection on Glue below that, etc., not too much different from the forum organization. Personally I find giant flat knowledge bases to be difficult to browse, i.e. you have to know exactly what you're looking for.

The downside to hierarchy is that someone must define it in the first place, maintain it (i.e. make sure things get put in the right place, and they often won't), and update it as the world changes.

 

[JohnCoker]

Well, I was imagining, for instance, a section on Techniques, and possibly a subsection on Glue below that, etc., not too much different from the forum organization. Personally I find giant flat knowledge bases to be difficult to browse, i.e. you have to know exactly what you're looking for.

The downside to hierarchy is that someone must define it in the first place, maintain it (i.e. make sure things get put in the right place, and they often won't), and update it as the world changes.

A hierarchy is good for the authors to organize the material, but most people are going to find it by searching. Provide good content and do some light SEO and you should be fine.

 

[rocketlabdelta]

There are (at least) three modes of discovery in a body of knowledge like this:

1. Known item search; you typed a specific query into a search engine or site search
2. Organic discovery; you follow an internal link from one page to another
3. Guided browsing; topic pages and/or overview pages link together related content for easy discovery

The discovery tools don't necessarily need to be built into the wiki engine. Good information architecture and technical writing can tie things together with appropriate curation.

One thing that is important is that the wiki treats phones as first-class citizens. A mobile-first responsive design is important to discovery and accessibility. MediaWiki doesn't ship with a design like that by default but Wikipedia uses one: Minerva Neue

 

[Jeff Lassahn]

People who are already familiar with a topic and are looking for reference material can usually rely on search to find what they need (assuming search is good which is a whole other can of worms). People who are new to a subject generally cannot use search effectively -- they don't know what they don't know, they don't know enough about what things are called, etc.

So if we're trying to write introductory material, it needs an organizational plan.
I agree the organization mechanisms don't need to be built into the tool, as long as the tool doesn't actively fight against creating a good organization. Some tools, particularly wiki-like tools do make creating structures, paths, tables of contents, etc difficult, though.

 

[cwbullet]

Should this focus on rocketry construction techniques?

 

[Tobor]

Btw, there are other technologies that can be leveraged to allow sustainability to this endeavor. The schema I have in mind involves decentralized distribution of a cloud based infrastructure. Think NextCloud and BitTorrent having a baby. I know this schema works because of it's use within the DarkNet and others of it's ilk.

It would be nice to see such tech used in a positive way. And no, I am not a programmer, developer or Keyboard Samurai.

 

[DaHabes]

Should this focus on rocketry construction techniques?

Construction techniques would be a main focus, but I have my "Tips & Techniques" folder broken down into many construction subtopics as well as non-construction topics. Some of the key ones include Recovery (tumble vs. streamer vs. parachute - rules of thumb, descent rate tables by weight vs. size of streamer/parachute; drogue vs. drogue-less, rear ejection), motor ignition (e-matches vs. igniters, making your own, lighting BP vs. composite, cluster ignition, air starts), AV bay alternatives (redundancy, switch alternatives, power alternatives, location (airframe vs. nose cone), BP vs. non-pyro, modularization for transfer between rockets, standardized wiring diagrams), Adhesives!, Finishing (ugh!), Materials (e.g, airframes - carboard, phenolic, fiberglass, carbon fiber, blue tube [properties, strength to weight ratios, usage and limitations]), Laundry Protection (wadding vs. dog barf vs. pistons vs. baffles vs. chute protectors), 3D Printing. It's a long list.

There is some back and forth in this thread regarding hierarchy vs. more free form. Given this is a contained topic (rocketry) and not a generalized Wiki (like Wikipedia), we have a fairly common build process hierarchy AND we have standards and rules to adhere to for safety, I weigh in on the side of a well defined hierarchy that is curated and moderated. Content should be moderated for the same reason. The last thing you want is unsafe content being added and propagated.

That said, I think it would be wise to have a core group of volunteers (a "steering committee", no less than 3, no more than 7, odd number so there there are no "hung juries") that begins to address these matters and makes decisions. These detailed oriented discussions need to be made outside of a forum like this, otherwise the effort will lurch back and forth. To do it right requires some organization and focus. If organized properly up front then once launched the content can be more self-sustaining by the general community. Virtual meetings monthly (perhaps more often during startup) to maintain momentum. After basic structure is in place, a call to additional content experts to curate and populate initial content. I would estimate a working, usable site within 6-12 months depending on progress. General availability limited until enough content is available to make it useful, lest people come, see not much and never come back. I volunteer to be one of the "founders". Doable? PM me if interested.

 

[lakeroadster]

That points out one of the risks of this kind of project that I have no idea how to deal with: if we build something online, it may eventually disappear or rot away even though it's valuable. How do we keep something like this alive and relevant so it can still be used 10 or 20 years from now?

Print it.. and then you have... a book. We've come full circle.

I love books. No technology glitches, no cell towers, no satellites, no batteries.