Skip to content

Welcome to Primrose

Sean T. McBeth edited this page Jun 5, 2017 · 5 revisions

My name is Sean McBeth and I started Primrose July 2014 just because I love programming and thought VR was neat. It grew and people started asking me how I was doing things that they wanted to do, so January 2015 I made it into a framework that would hopefully help people make VR apps for themselves. VR is exciting and lots of people want to get involved in this growing movement, but it's also hard to build things. I thought I could make it less hard for people, maybe even easy.

We hope to make Primrose into a project where anyone can feel comfortable getting their feet wet in programming. We believe that Virtual Reality is going to change the world for the better, and we want to be a part in making that change. That change starts with us making sure we're open to helping others wherever necessary.

Difficulty Level

Virtual Reality can be a difficult affair. There is a lot of 3D graphics programming and applied mathematics involved. But that is really only a small part of the total project. So we want to show that any person of any skill level, of any area of focus, can make a contribution to open source software.

First Timers

To that end, we're trying to keep a collection of very simple, one-line-of-code tasks in the Issues List that are meant for beginners to use to get used to getting the project set up, making changes, using Git, and submitting pull requests. Look for the first-timers-only label.

Beginners

We'll also be trying to keep a collection of easier tasks that have more changes necessary, but where the direction is very clear on what needs to be done. These will be marked with the easy tag. If you already know how to use Git and submit pull requests, but don't feel you are strong at JavaScript, this would be a good place to start looking. Again, please leave the first-timers-only tasks to the people who need the practice.

Novices

After the easy issues are the medium issues. These are basically tasks that I know how to implement, but I haven't sat down and figured out all the details. They'll probably take one or more days to complete. Intermediate people will probably have to ask questions on what the issue means and how to implement the changes. The comments in the Issue are a great place to do that. We will strive to break those tasks down into several easy tasks as we have time to review each of them, but if you feel up to the task, by all means jump in.

Advanced

Any tasks that we haven't even started figuring out, but know that it will take at least a week, or longer, to complete is a hard task. These should first be broken down into medium tasks by conducting research into options that are available, how they might fit into Primrose, and how the work should be scheduled to make sure the change is performed successfully without being a major disruption to everyone else. Usually a very experienced developer would be doing that break down, but again, anything is up for grabs.

Other

And the tasks won't be only VR or 3D or math programming. There's lots to do, even if you might not feel comfortable getting into the advanced stuff right away or want to take more time to learn. There are a lot of changes that will need to be made to the website itself, things like fixing the layout of the documentation site, or making the documentation easier to read, or creating a video tutorial section, or a user showcase section. Every project is always in need of graphic design, 3D modeling, web development, demo development, testing, documentation, blogging and vlogging of your experience or whatever you build as you go.

Everyone has some sort of experience to bring to bear on a project. Nobody is unimportant, and no one person's work is more important than another's.

"Rules"

For 15 years I worked at companies with lots of rules. It was terrible, because most of them were arbitrary, like "you can't wear a skirt to work" (and I'm totally not afraid to admit that a kilt is a skirt). So when I say "rules", I don't mean, "things you can't do". I mean, "things that are meant to guide you to do well."

Rule #1: Be bold.

I'm not going to berate you for doing things "wrong". I hated that sentiment when I was a beginner 20 years ago and I don't want to repeat it here. If everything goes well, anything that is technically "wrong", you will learn organically why you might want to do it "right". If I can't convince you, then it probably isn't "right".

When you're using Git, nothing is ever truly broken. Code style is a trivial issue and I'm not a picky person. Bugs exist in everyone's code. I can fix anything you break, so don't worry about breaking anything. It's inconvenient, but not the end of the world. You never know who is going to be able to help you get around an issue, so optimize for action.

Rule #2: Be confident.

If you assume I'm always right, you'll assume you're wrong if you don't understand something I've written. I'm just the guy who started this project, who has spent the most time on it. That doesn't make me a god. There are lots of places where I was just guessing. And by "lots", I mean "most".

If anything at anytime is confusing or seems inconsistent, you're probably right. I'm here to help you learn, so don't be afraid to ask me questions, anywhere you feel most comfortable.

That means don't be afraid to change something I've written. Nobody owns this code. Code is discovered. [0] And code that does not fit for its purpose today is code that needs to change immediately, no matter how long it may have fit before. We don't write programs in the past.

Rule #3: Be nice.

I have one "don't" rule, one place I am strict: don't intentionally make anyone else feel bad, and apologize if you unintentionally do so. I wish I didn't have to say this and it was just assumed. We assume it when we talk to each other in person. But for some reason, people online sometimes forget that they are talking to other, real people. That's all I'm asking, please be the sort of polite individual that we expect out of each other when we meet in person. Always remember there is a real person on the other end of the TCP/IP connection.

OK! Have fun!

At this point, you are probably bored of reading and want to get to work. If this is your first time working on a programming project, please read the instructions on Prerequisite Tools. After that, please next read Working on Primrose.

Footnotes

[0] In the metaphysical sense. We have to maintain a legal ownership to make sure nobody steals it away from us. That's the point of the GPL license and the concept of copyleft.