Update projects/

[Joedang]

So, rather than trying to do shenanigans with Jekyll, I think it's better to leave the structure of the site as-is and just update the content in the markdown files. (I wonder who could have told me that already...)

Maybe "someday" things can be set up so that all the project descriptions aren't all in one file. I wanted to do a top-down approach, tweaking the page layouts to allow each project to be its own file, with the super/sub-project structure mirroring the directory structure... but I've made no progress with that, so bottom-up it is!

Questions to be answered

• Which projects are dead or irrelevant?
  • Should we have a separate page for "past projects" or should they just be removed? All projects should be marked as "active" or "inactive" in the list
  • How do I view the issues I've raised on other repos, lol? I'm not sure which "Is this dead?" messages went unanswered. I guess I'll just go through the list again.
• Which things from the meeting notes count as super/sub-projects? See below conversation.
  Presumably, Oresat is a super-project, much like the LV2 hardware was a super-project, for example.
  • Does OreSat count as a PSAS project? I mean, it has its own website, so does it go on the PSAS website? Yes.
• Do we really need all those horizontal rules? They seem to make the source files a lot more cluttered without adding much ease-of-reading to the rendered site. No, adding h-rules in markdown is inevitably inconsistent and makes the markdown harder to read. h1, h2, and h3 headings now automatically get h-rules of decreasing weight.
• Is the ToC really necessary? Yes, it totally is.
• Which new projects need those fancy language and build-status tags?
• Should the stuff from LV2 be removed? Presumably, we are no-longer working on anything LV2 related. No, it should just go to the bottom of the page and be tagged as 'inactive' or 'deprecated'.
  • Which LV2 projects are being carried over into LV3?

Things to be done

Presumably, there will be more items on this list, depending on how the above questions turn out.

• Make a whitelist of projects that are definitely not dead
  • Projects that have given updates in the meeting notes since the new year
  • Projects that have had a commit since the new year
  • Poke the people involved with all the listed projects
    • Follow up on which projects did not respond to "Are you dead?" messages.
      Most of the issues asking if a project is active/inactive went unanswered (unsurprising). I'm going to leave them open, just in case someone is being lazy.
• Bug people involved in newer projects about what they might want mentioned and if they need those tags for language and build-status.
• If people say they know a particular project is dead, add it to a blacklist. I haven't heard anything, but it would be good to ask, once I have a draft of the projects page.
• Restructure the headings in the projects list to fit the new distribution of projects.
• Begin adding projects from the tables below. Anything marked with "N" still needs to be added. Remember to mark things with "Y" once they've been added.
• Add the OreSat repos!
• Rearrange the nav bar tabs. (See below.) (Can we insert the rockets/ content into projects/ without copy-pasting?)

Criteria for success

• Get one or two new peeps to read it to see if it makes sense.
• Scroll through the project headings during a meeting to see if anyone complains that their stuff isn't listed.

Active Projects

(This should be editable by anyone.)
These projects should be marked as active.

project name	added?	notes
telemetry	Y
launch tower	Y	should be double-checked for compatibility with LV3
countdown	Y	should be updated for LV3
procedure book	Y	This may need to be updated for LV3.
launchtower-comm	Y	Glenn says Paul is working on this.
flight-director-table	Y	Glenn says Miles is working on this.
GPS	Y
CG RCS	Y	needs more description
liquid engine analysis	Y	Should be combined with 100km-design and renamed LV4-design?
lv3.0-airframe	Y	replaced LV3-design
DxWiFi	Y	Relevant to LV3 and OreSat, even though one of the repos is inactive.
psas.pdx.edu	Y	Obviously, we should keep this.
publicity	Y	Why doesn't this have a README?! (and why can't I add an issue for that?)
blog	Y	Should link to the actual blog, not the repo.
recovery + eNSR	Y
electric feed system	Y
composite tanks	Y
Rocketview	N
Liquid fuel engine	Y

Inactive Projects

These projects should be marked as inactive.

project name	added?	notes
360 camera	Y	repo: sw-cad-airframe-lv2.3; 360 cam might one day be relevant to LV3
LV3 Design	Y	superseded by lv3.0-airframe. It might actually be nice to finish this document and update what's there to a current description of LV3.
roll-control	Y	superseded by the cold gas RCS
cylindrcal patch antennas	Y	There are no plans to add patch antennas to LV3... It also links to an empty repo. (Should the other antenna repos be submodules of the main psas/antennas repo?)
stm32	Y
av3-fc	Y
elderberry	Y
psas_packet	Y
camera-automation	Y
avionics-cad	Y
commander	Y
Carbon Fiber	N	Should become "LV3 hardware" and be a superset of lv3.0-airframe, eNSR, lv3.0-recovery, etc.

[hmarie2]

Joe, This is awesome!! We can definitely go over your status, updates, and any remaining questions at Sunday's leadership meeting. Good luck! Marie

On Wed, Feb 15, 2017 at 4:47 AM Joe Shields ***@***.***> wrote: So, rather than trying to do shenanigans with Jekyll, I think it's better to leave the structure of the site as-is and just update the content in the markdown files. (I wonder who could have told me that already...) Maybe "someday" things can be set up so that all the project descriptions aren't all in one file. I wanted to do a top-down approach, tweaking the page layouts to allow each project to be its own file, with the super/sub-project structure mirroring the directory structure... but I've made no progress with that, so bottom-up it is! Questions to be answered - Which projects are dead or irrelevant? - Should we have a separate page for "past projects" or should they just be removed? - Which things from the meeting notes count as super/sub-projects? *Presumably, Oresat is a super-project, much like the LV2 hardware was a super-project, for example.* - Do we really need all those horizontal rules? They seem to make the source files a lot more cluttered without adding much ease-of-reading to the rendered site. - Is the ToC really necessary? Yes, it totally is. - Which new projects need those fancy language and build-status tags? - Should the stuff from LV2 be removed? Presumably, we are no-longer working on anything LV2 related. - Which LV2 projects are being carried over into LV3? Things to be done *Presumably, there will be more items on this list, depending on how the above questions turn out.* - Make a whitelist of projects that are definitely not dead - Projects that have given updates in the meeting notes since the new year - Projects that have had a commit since the new year - Poke the people involved with all the listed projects - Bug people involved in newer projects about what they might want mentioned and if they need those tags for language and build-status. - If people say they know a particular project is dead, add it to a blacklist. Criteria for success - Get one or two new peeps to read it to see if it makes sense. - Scroll through the project headings during a meeting to see if anyone complains that their stuff isn't listed. Whitelist *(This should be editable by anyone.)* project name added? Blacklist project name added? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQWmfabpCT9-rrh2kpEXQj8-t7GipUykks5rcvPzgaJpZM4MBrHd> .

-- Marie

[Joedang]

It might be better to have a "past projects" section/page, rather than just nuking everything from LV2.3... That a lot a neat stuff to not brag about.

[glennl]

I strongly agree, and expect Joe might just be planning on moving anything not spoken for to an "old" or depricated area? - Glenn

…

On Feb 18, 2017 2:03 PM, "Joe Shields" ***@***.***> wrote: It might be better to have a "past projects" section/page, rather than just nuking everything from LV2.3... That a lot a neat stuff to not brag about. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB2tbBCHU_ed9ga0bvyVf-Hdw3aU5Avbks5rd2qdgaJpZM4MBrHd> .

[Joedang]

Yes he/I is/am.

[7deeptide]

I also strongly agree. Any repos that are part of our current workflow should be included in "current projects" regardless of when their last commit was. Besides bragging rights, past projects might be of use to someone in the community so we should add and highlight a past projects section and/or page with slightly more contextual narrative in the project description than is currently the case.

[7deeptide]

@natronics @Joedang @andrewgreenberg Also, on the broader topic of project organization, should we have a consistent scheme for repo organization/hierarchy? For instance, should we merge the various composite airframe/liquid propulsion/LV mission design/etc. repos to make organizational heirarchy apparent from the repo structure, or should that be left to the projects page on the website?

[Joedang]

IMO, merging repos together might make it harder to find things. I also don't think it would benefit us much organization wise. Like, if the airframe and test stand/liquid engine were together, I think I would just work on a different branch, since changes to the airframe don't really affect the test stand/liquid engine (and vise versa). But, maybe that's the "proper" way to use Git anyways.

Maybe it would make sense to have an "psas/current" repo with all the repos as submodules, but I feel like that would be just as good as the list on the website (and probably harder to maintain too).

[7deeptide]

I think I've precipitated a misunderstanding. I wasn't proposing that we merge all current repositories. I'm asking what makes the most sense as hierarchical levels for projects and repos for organization purposes. A criticism I often hear from newcomers to PSAS is that they can't make sense of PSAS's projects from looking at our github structure, or that they don't know where to find information about a project that may be divided amongst several git repos.

LV3 or LV4 as organizational levels is possible, but I agree that it wouldn't necessarily be very useful. However, liquid propulsion, or composite airframe could be useful levels. For instance there are several composite airframe repos (4?). I would definitely propose merging some of these...

[Joedang]

Yeah, I still don't really know how the ECE/CS type stuff is structured. Like, it seems that there are some things which are inactive but still relevant, so you couldn't get a good idea of the relevant projects just by looking at github.com/psas.

I kind of wonder if it would be useful to tag the different projects with "ME", "ECE", "CS", "Capstone", etc., since it seems like a lot of new people come in saying "I'm a <major> major, so I'd like to work on a <major> project." It might also be neat if there's a way to show the last-updated date for a repo, similar to how the build statuses are shown.

I was imagining I'd organize it into something like this:

• Current projects
  • LV3 hardware
    • Carbon fiber fuel tank
    • Electric fuel pump
    • Airframe
    • Recovery system / eNSR
    • RCS
  • LV3 electronics
    • Launch tower computer
    • (This is a spot where the blurred line between PSAS/LV3 and OreSat gets awkward. Like, isn't OreSat part of LV3 i.e. the flight computer?)
    • LGR
    • Power board
    • DxWiFi
  • LV3 software
    • SDR GPS
    • Rocketview
  • LV4 / research
    • Liquid fuel engine
    • Test Stand
• Past projects
  • LV2 hardware
  • LV2 electronics
  • LV2 software

[7deeptide]

EFS and CF Propellant Tanks are for LV4 not LV3. Liquid-engine-analysis is kind of a misnomer at this point as it has little to do with liquid propulsion per se, really what it encompasses is LV4 conceptual design. Regarding LV3 avionics, I think that it's ok to link to Oresat repos in the PSAS projects page where applicable, but it should be clear where those repos fit into the LV3 con ops/work breakdown structure. Maybe the project pages would benefit from some block diagrams?

On the topic of the horizontal rules, I agree. Could they just be replaced with some added whitespace?

[Joedang]

@7deeptide Yeah, I think a block diagram of the systems in LV3 and LV4 (maybe with the names/URLs of the corresponding repositories) is a really good idea. I'm imagining something similar to the L-12 network diagram. I'll remember to put fuel pump/tank stuff in LV4. LV3 and LV4 just fall under "the new one" in my mind.

As for the h-rules, I found out how to control that through CSS, which actually looks kind of nice. For completeness' sake, yes, you can force whitespace into markdown by using  , but it's a lot more elegant to do it in CSS, IMO.

@natronics or anyone who knows, really, do you have any idea how to get this repo to point to the latest version of the _layouts submodule? I made a change to the base.html layout, but when I do git submodule update, it detaches _layouts from the master branch to the earlier commit.

@FrancescaFr Here are my notes from the Sunday meeting:

• Have an onboarding page separate from the projects page? (I think this is more of an "enhancement" thing than an "update" thing, and should be done after the updating)
• Maybe have a cool videos page? (another enhancement)
• List Oresat as a project within PSAS? Yes.
• Put the dang callendar on the front page!
  • Figure out how to give an event view rather than a calendars view. (This is not a thing, as far as I can tell. Google doesn't seem to allow much customization for embedded calendars.)
• Is there a way to have an image gallery? (This seems like something very Jekyll-esque. I'm reasonable sure there is a template for it out there.)
• Monthly updates to the website. (Ask on the first meeting of each month.) (Ugh.)
• While we're at it, update the launch page to say "summer" instead of "spring." :( (I think this will have to be done through the countdown repo.)

Order for the tabs (should be a simple change to _config.yml):

• About
• Getting Involved
• Launches and Events (videos go in here)
• Projects

[natronics]

Quick tutorial on git submodules:

They're terrible, but there isn't really any other way to keep multiple repos together with shared code (e.g., if we have multiple sites but they all have the same css and page headers, etc. which is exactly why I submoduled _layouts).

---

How to clone a repo with a submodule inside it (you only need to do this once):

$ git clone _whatever_
$ git submodule update --init

Then if you want to change what commit the submodule is pointed at (either forward or backward), cd into the directory that is the submodule, it's its own git repo!

How to change what commit a submodule points to:

$ cd _layouts
$ git checkout asdf1234

Now when you go back into the main repo (not the submodule) you'll see that folder has "new content"

$ cd ..
$ git status
On branch master
Changes not staged for commit:
    modified:   _layouts (new commits)

Now you just stage and commit the submodule

$ git add _layouts
$ git commit -m "Changed the '_layouts' submodule"
$ git push

---

For a concrete example:

How to update the _layouts folder in psas.github.com to latest commit:

$ cd _layouts
$ git pull
$ cd ..
$ git add _layouts
$ git commit -m "Update '_layouts' to latest version"

[Joedang]

Now you just stage and commit the submodule

Yaaaas, I don't know why I didn't try that. Thank you.

[Joedang]

@jameysharp I'm not sure what to write for the Rocketview 3000 description. Any ideas? (Also, is it called Rocketview or Rocketview 3000?)

[Joedang]

Also, I have the same question for Rocketview, LGR, and the Power Board: What descriptions do you want and what repo should I point to? @wrh2 @glennl @OutboundFlight Any thoughts?

https://github.com/psas/psas.github.com/blob/master/projects/index.markdown

E: Here they are:

• https://github.com/oresat/low-gain-radio
• https://github.com/oresat/system-controller
  (of course, many other of the Oresat repositories should be added too.)

[jameysharp]

We don't have an "official" name for the current CS capstone; Andrew and I have been calling it either "Telemetry Bling" or "Rocketview 3000" because those names amuse us. The existing telemetry software we used for the last couple launches is in a repo simply called "telemetry", but before that our earlier versions of the same idea were all called "Rocketview", going back to Bart's original Gtk+ app in 1999. We also have a history, dating to around the same time, of calling things "<something> 3000", because it was 1999 and "<something> 2000" was obviously not futuristic enough. So we had the "Trackmaster 3000" shoulder-mounted antenna, for instance.

Long story short, let's just call it "Rocketview 3000" and be done with it. For a description, how's this:

During the rocket's flight, it streams data from its sensors and internal state over Wi-Fi to the ground. We use the psas/telemetry repo to visualize this telemetry stream in real-time, and to make the live telemetry web-accessible from anywhere in the world.

The Rocketview 3000 project is a CS capstone to improve visualizations we can use for this telemetry data, with two broad goals:

1. Better logistics awareness (so we can tell at a glance whether recovery teams are in position, for example);
2. Pretty visualizations for publicity (so strangers on the Internet will get excited about our work).

[Joedang]

Notes from the leadership meeting:

• Reduce the number of levels in the ToC.
• Remove the ToC heading.
• Eventually, make a block diagram for LV3.
• Make major project headings more verbose/narrative.

[jejor]

@Joedang the /launches/ page needs to be updated with lv3.0 launches. ditto /rockets/ with lv3.0, lv3.1, and lv4.0