openfarmcc / openfarm

A free and open database for farming and gardening knowledge. You can grow anything!

Security Concerns

We take security seriously and value the input of independent researchers. Please email [email protected] for issues that require immediate attention. Please follow responsible disclosure. Do not use Slack or Github issues to discuss security vulnerabilities.

The Community of Contributors: How it Works

About

OpenFarm is a free and open database and web application for farming and gardening knowledge. One might think of it as the Wikipedia for growing plants, though it functions more like a cooking recipes site.

The main content are Growing Guides: creative, crowd-sourced, single-author, structured documents that include all of the necessary information for a person or machine to grow a plant, i.e.: seed spacing and depth, watering regimen, recommended soil composition and companion plants, sun/shade requirements, etc. In this Freebase platform, gardeners can find answers to questions like “How do I grow tomatoes?”

Start by Joining Existing Contributors

To start the discussion, get involved, and meet OpenFarm core community of contributors, we strongly recommend joining our Slack room! This is where you'll find the latest conversation about Openfarm and the most active contributors.

Check also the FAQ for some frequently asked questions about contributing (Angular, Issue Trackers, IRC Channels).

Check the ongoing issues that need work on in the priority list.

Look for Something You Want to Work On

For front-end and back-end code contributions, we aim at maintaining and prioritizing the Github issues through Github Projects, the Trello-like web-based project management board of Github: OpenFarm Projects.

Need to use OpenFarm Assets? Here they are!

We have few more languages missing for the website content to be translated: help us translate the website!

Who Can Contribute

Everyone is welcome to bring value to the Open Source community of OpenFarm. Time is our most valuable assets here, so any minute of your time counts to make things happen! "Better done, than perfect!" We strive for diversity in our community and want to ensure we provide a safe and inclusive space for everyone by adopting a Code of Conduct.

Our community is composed of tech and non-tech folks, newbie as well as experts in gardening, overall great people willing to take actions for a better future and sharing knowledge and growing our own food.

Our problem-solving process

On the way we work together, we aim at:

• having transparency in reasoning behind actions: taking time for documentation, questions and answers
• prefering done, than perfect: breaking down tasks so that anyone can contribute few minutes of their time on a regular basis
• taking shortcuts: what's the most obvious for a better usability? what's the shortest way to build a feature? What's the most valuable inputs for a feedback?

Development

Getting Started (The Easy Way)

You should use Vagrant to get the OpenFarm system running on your computer. It will avoid having to install the things listed in The Hard Way below.

1. Install Vagrant.
2. Install VirtualBox.
3. Open your terminal.
4. $ git clone https://github.com/openfarmcc/OpenFarm.git - this tells your computer to fetch the data stored in this repository using git.
5. $ cd OpenFarm - change to the OpenFarm directory.
6. $ vagrant up This will take a long time. We're downloading a whole bunch of stuff. Go make yourself a pot of coffee, or brew some tea. If something goes wrong at this point, reach out to us directly via GitHub issue.

Accessing Vagrant

Once Vagrant is set up on your system, you might want to actually access it. For example, if you want to start up the server (though vagrant up should run rails s for you):

8. $ vagrant ssh - this makes you access the new virtual server we just created to run OpenFarm on.
9. cd /vagrant - the vagrant directory is mirrored in your own computer. If you add a file there, you'll see it appear here.
10. rails s - actually run the Rails server!
11. you should now be able to access OpenFarm on your local system at http://localhost:3000. If all went well, you will have a seeded database and can use the account [email protected] with password admin123.

The above is still being patched, so please reach out to us if something went wrong!

Getting Started (The Hard Way)

You will need to install Ruby, Rails, ElasticSearch v6.5.0, and Mongodb before you can get an OpenFarm server up and running on your local machine. Once you have these prerequisites to get started with a local copy of the project, run:

$ git clone https://github.com/openfarmcc/OpenFarm.git
$ cd OpenFarm
$ bundle install
$ rake db:setup
$ echo "ENV['SECRET_KEY_BASE'] = '$(rake secret)'" >> config/app_environment_variables.rb
$ echo "ENV['GOOGLE_MAPS_API_KEY'] = ''" >> config/app_environment_variables.rb # or get an actual API key at https://console.developers.google.com/flows/enableapi?apiid=maps_backend&keyType=CLIENT_SIDE&reusekey=true&pli=1
$ rails s

Then, visit http://127.0.0.1:3000/ in your browser to see the OpenFarm web application running on your local machine. If all went well, you will have a seeded database and can use the account [email protected] with password admin123.

Note about ElasticSearch: Some Linux users have noted issues installing ElasticSearch onto a host machine. One workaround is to install ElasticSearch via Docker:

sudo docker pull elasticsearch:6.5.0
sudo docker pull mongo

sudo sysctl -w vm.max_map_count=262144 # <= Some linux users must run this
sudo docker run -p 9300:9300 -p 9200:9200 elasticsearch:6.5.0
sudo docker run -p 27017:27017 mongo

If you had any problem installing bundles getting up and running etc see the Common Issues Page.

Remember that /vagrant folder in the Vagrant VM is largely for convenience, and working in it can cause unexpected behavior with other tools - you should do your work in your own non-vagrant environment. Use the environment you're most familiar with to program, and Vagrant will do the rest.

Become a Core Contributor

If you've made two PRs, we'll add you as a core contributor.

For core-code contributors, here are a few basic ground-rules:

• No --force pushes or modifying the Git history in any way.
• Non-master branches ought to be used for ongoing work.
• External API changes and significant modifications ought to be subject to an internal pull-request to solicit feedback from other contributors.
• Internal pull-requests to solicit feedback are encouraged for any other non-trivial contribution but left to the discretion of the contributor.
• Contributors should attempt to adhere to the prevailing code-style.

(based on the OPEN open source model)

Further reading

Actual Code Contributors

Here are some of the Github contributors.

Outside of Github, there's a whole host of people who also contributed financially, by building gardening content on the website, on providing more visibility for OpenFarm in any ways!

Donate to OpenFarm as a Backer

Support us with a monthly donation and help us continue our activities. [Become a backer]

Support OpenFarm as a Sponsor

Become a sponsor and get your logo on our README on Github with a link to your site. [Become a sponsor]

Software License

The MIT License (MIT)

Copyright (c) 2019 OpenFarm (http://openfarm.cc/).

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Data License

All data within the OpenFarm.cc database is in the Public Domain (CC0).

openfarm's Issues

Add description to "Soil Type" and "Preferred Growing Method"

When you sign up (create user) there might be a good idea to add a option list with different "Soil Types" that the new user can select from. And a link to a guide how to determine ones soil type.

Add a couple of suggestions to the "Preferred Growing Method" to get the new user think in the right direction.

Style Guides.

It makes sense to create a series of code style guides for HTML/JS/CSS.

We can make our own, or just steal some from others.

CSS options: http://css-tricks.com/css-style-guides/
JS the Airbnb one is pretty good: https://github.com/airbnb/javascript

These could just be pages on the wiki for people to refer to, and could evolve as the codeset progresses.

It would also be a good place to define styles on top of the Foundation presets.

Thoughts?

Guide page should have Contents area linking to other sections

HTML bookmarks: #prerequisites, #timeline, #instructions

Add instructions for bootstraping application

Add setup instructions

Split application into client side & server side

[enhancement] Just saw the new OpenFarm mockups on kickstarter and wold like to get involved.

The new UI looks fairly sophisticated. I suggest splitting OpenFarm into a client side & server side application - or at minimum, use a js framework instead of rails views. Anyone open to Angularjs?

Landing Page search area CSS mishap in Firefox

For whatever reason your landing page is rendering all weird in Firefox.

Iconography

I'm seeing all sorts of icons on a bunch of pages. Can we put all of those together in a font so that they're easily re-usable, easily accessible, etc?

IcoMoon does this as a service for free, as long as we have vector graphics to put it up.

Guide page tooltips!

For the following elements:

• Guide rating: "4.1 out of 5 stars from 37 reviews"
• Compatibility elements: "60% match because ____"
• Timeline vertical bar for today: "Today is Feb 21"
• Timeline horizontal bars of time: "95 days"
• Timeline vertical bars for major events such as last Spring frost: "Estimated last Spring frost: Mar 14"
• Growing Instructions unit conversions
• Growing instructions bar graph value: "Water 14 Liters/Plant, every day"

Architecture

Hello! I was wondering if there had been a discussion of architecture yet? I saw that the repo was setup with PHP. I personally don't know PHP, so I had imagined using Rails or a JS MV* sort of framework for myself and to help keep things in-line with the other side of the project slash make it approachable to everyone on the project.

As I said, I don't know PHP so I could be missing out on its advantages, but I think Rails would especially lend itself well to this project, especially to get things up as quickly as possible. Just my two ¢ents!

Users should be able to create an account

Flesh out UX/UI before continuing development

Getting the project up an running, it is not entirely clear what the purpose is. Does anyone have thoughts on the UI features? Is a CSS framework alright like Bootstrap or Foundation? Any preferences?

skype/irc group

Can we get a group of active devs together on hipchat, skype, irc or something to bounce questions/ideas/current tasks around?

Guide pages should have collapsible sections

Sections for first release are: Overview, Prerequisites, Timeline, and Growing Instructions

Users should be able to edit their user data

Frontend framework and responsiveness

Do we want to use a frontend framework such as Bootstrap or Foundation? Lots of users may be accessing the site from mobile when at the nursery or in the garden, so a responsive design is imperative.

The Guide page mockup was designed on a 12 column grid, so it could port well to soemthing like Foundation in that regard.

Deprecated functions

When opening the landing screen in Ubuntu, we get "deprecated" warnings. Different ones in Firefox and in Chromium.

In Firefox:
Use of getPreventDefault() is deprecated. Use defaultPrevented instead.

In Chromium:
event.returnValue is deprecated. Please use the standard event.preventDefault() instead.

Collaboration Forum

No place to communicate with the contributors of this project to prevent overlap of backlog. Also backlog doesn't appear to contain any work ready to be carried out in bite sized chunks..

Add license

Add license. Any preferences?

Guide compatibility elements should change background color based on percentage match between user and the guide

Background remains gray if user is not logged in or has not given us data to compare to

Users should be able to add multiple photos plant records

Users should be able to search plant data from front page

Users should be able to add plants to the database

Need a mail server on the production machine

Compatibility Score badge should change color based on percentage

You know a thing or two about color, right @warpling? ;)

Users should be able to delete their account

Add tags to sun_requirements and sowing_method. See mongoid_search docs

Guide page should have an OpenFarm search box in the navigation

Consider using Angular JS for the front-end

Would you guys consider using a client-side framework like angular js instead of using server generated pages? Yeoman (yo, bower, grunt) is a nice front-end tool suite that could help stream line the process.

Style Tiles

I want to start defining the visual style for open farm, as I'm coming across several places where I'm deferring to the Foundation styles, and I'm not sure that's a good thing long run.

Example:

http://style.codeforamerica.org/ (the styles here would just power the entire site).

Users should be able to register via facebook or twitter

Landing screen 'OpenFarm' logo is cut off in Ubuntu Firefox and Chromium

Here's a screenshot of my 3 monitors (didn't feel like cropping the screenshot :) ):
http://i.imgur.com/CwZ75a1.jpg

Middle screen is Firefox, right screen is Chromium.

Creating Guides Wireframes

I've been taking some steps to think about the creating guides steps.

Here's an initial design (bonus - also exploring a visual direction for openfarm).

Here's my reasoning for splitting things into a couple of steps:

Steps 1 & 2 are gathering basic information from the user, stuff we want them to definitely include in a guide.

Step 3 I was seeing similar to how you mentioned seeing it @roryaronson. The box could expand in width, and start looking like the actual guide. I like the idea of consistency there, but that might be something we need to try and actually build, and see how it works in action (this is one of the reasons I want to try VWO). The current edit page is actually a step towards that - pretty WYSIWYG.

I'll explore that a bit and show it here when I'm done with it. I'd love feedback/input on visual style as well - don't consider myself a visual designer at all.

need custom 404, 500 error pages

Flash Alerts leave trailing whitespace when active.

Screenshot: http://imgur.com/zhzsumC

When an alert is active, it's surrounded by white.

Flash/Alert dialog buttons not closing dialog

I bet Jquery got messed up in the asset pipeline. Will investigate when I finish what I'm working on right now. If someone else wants to investigate this one, go nuts.

Binomial names and the endless complexity of categorizing life

I thought I'd share what I learned while researching naming conventions for Practical Plants.

A binomial is composed of the genus name and species epithet: e.g. Brassica oleracea (binomials should always appear in a contrasting style to the surrounding text, most commonly italics). This is not enough information to refer to the majority of cultivated plants, since there are almost always numerous varieties, sometimes representing very different plants with entirely different needs. For example, the single Brassica oleracea species represents the thousands of cultivars of Cabbages, Broccolis, Kales, Coliflowers, Brussel Sprouts and so on. Advice and data for one species can be entirely irrelevant for another.

There are several systems of sub-species categorization used for plants, used often interchangably, and equally often incorrectly. Browsing plant data online you'll often see epithets like var. convar. ssp. etc.

In my research I found the following is generally seen as 'correct': use var. when referring to a naturally occurring species variety. There are some cases when one should use ssp. (subspecies) for some subtle botanical distinction which I don't remember. Most relevant for Open Farm is ICNCP which should be used when referring to a registered cultivated variety. It also provides a means to refer to cultivars which share characteristics as a group, which is crucial.

E.g. Cabbages are a member of the Capitata group Brassica oleracea Capitata Group, and Brocolli are grouped as Italica Brassica oleracea Italica Group.

and one may refer to one of my favourite winter cabbages, January King by any of the following:

• Brassica oleracea 'January King'
• Brassica oleracea (Capitata Group) 'January King'
• Cabbage 'January King'

The cultivar name must always be enclosed in single quotes, and capitalised. The group must be enclosed in brackets if present, but it is not required, and should be capitalised. The last example is informal and useless for categorization.

On the opposite end of the scale, it is not uncommon for a plant common name to actually refer to an entire genus of plants made up of many very similar species with the same requirements and care conditions, and so the binomial is actually too specific.

Accordingly, I recommend a subset of these properties exist in order to categorize which plant a guide belongs, the only mandatory entry being taxonomic rank and genus:

• taxonomic rank (genus, species, subspecies, variety, cultivar group, cultivar)
• genus
• species
• cultivar group (optional even when cultivar name is set)
• cultivar name
• subspecies
• variety

Since common names are so variable, not just from language to language but between regions, I think these are best represented as their own document rather than attached to a guide. That way a user can search by the common name they know and find all relevant guides. It would also allow the guide author to simply enter the common name they know and, if it has already been entered by someone, the remaining taxonomic information could be auto-filled.

Information Architecture

Heya folks, I've just had a look at the Drive, and can't seem to find an over-arching information architecture for the site.

From discussions on this site it looks like people have a fairly strong understanding of how the site will be built, and what the structure would look like, but in the interest of making sure that everyone is on the same page, and making it easy for newbies to jump in, I was wondering if such an IA should be put together, talked about, etc.

I'm happy to put what I understand into a diagram, and see if people agree, but wanted to make sure that something similar didn't already exist.

Development Branch

Should we have a development branch alongside a proper release cycle?

I say this because it makes more sense to focus on specific parts of the application and release them one by one through the master, rather than just keeping the current website on the same branch as the development is going.

It might also make sense to instate semantic versioning for any API we decide to build?

Regular updates

As we head into the realm of a constantly updating project, we probably need a blog and email list with regular (bi-weekly?) updates about the project and where it's headed. We can use some service like tumblr for a quick blog, and probably something like mailchimp (first 2000 emails free per week), or sendy when we get beyond that.

Being in regular touch beyond kickstarter is important I reckon, and we need a way to contact people who aren't in the mood to pay for kickstarter.

Users should be able to explore and stuff. (not search)

Install Google Analytics

I created an analytics account, here is the code that needs to go in every web page we want to track:

<script> (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,document,'script','//www.google-analytics.com/analytics.js','ga'); ga('create', 'UA-54082196-1', 'auto'); ga('send', 'pageview'); </script>

Guide model architecture

Hey all, wondering what structure everyone is imagining for the Guide models. As far I understand things so far, Crops have many guides and guides belong to a User. Guides can be grouped via a common crop name (eg. "Tomato") or a specific variety (eg. "Cherry Tomato").

As far as the architecture for the Guide model, how should the data be structured?. Straight up as strings for now? Enums? Tables of values such as soil type?There's a lot of data to store from dates, to hardiness types, to watering amounts.

Forgive me if this discussion has already been had elsewhere and earlier! 🇺🇸

Log production errors / send alerts to admins

ngdebounce not updating in /guides/new form

AJAX search box in /guides/new ?

Perhaps we should have an ajax search box that finds crops by ID rather than by name to prevent duplication of records in guides.

NOTE: It looks like simon already started this feature.

Add a 'Fork me on GitHub' Ribbon

The black one would look nice below the header: https://github.com/blog/273-github-ribbons

Search Page Field Cuts Off Characters (Display Issue)

The search box at http://openfarm.cc/ cuts off the characters of the font.

Using Firefox 31.0

Here's a screenshot where I have typed "corn":

Hardiness / Heat Zone / Growing degree days

I saw USDA hardiness and AHS heat zones mentioned in the Guide wireframe so I thought I'd bring it up for discussion.

USDA hardiness zones are a mostly U.S. specific metric (some other systems are in use to model climate factors in other countries like Australia and Canada) based on minimum winter temperatures and give a very approximate indication of the ability for a plant to survive in a given climate. It does not indicate a plant will prosper and because it only measures minimum winter temperatures, locations with similar winter temperatures but different summer temperatures will be given the same hardiness zone. Nonetheless it's a useful indicator when used appropriately especially for perennial plants like fruit trees. For the most part, it's irrelevant for annual crops where summer temperatures are usually the most important metric.

AHS heat zones give the average number of days a particular location experiences temperatures of over 30ºC. It's a proprietary system with, to my experience, almost no practically useful data available. Most flowering plants do not mature any faster over 30ºC, so I'm not sure why this metric exists.

Growing degree days are a cumulative tally of hours of average daily temperatures. They can be used very reliably (and is used in industrial agriculture) to indicate when a crop will flower, when fruit will mature, etc. There is a decent amount of data available for various species and specific varieties commonly grown in industrial agriculture, but not much data available for less common garden crops. It's relevant to growers in both indoor/controlled and outdoor environments.

In short, I think OpenFarm should definitely include USDA hardiness zones where possible, with some way to clearly indicate it's only relevant in regards to minimum temperatures, and absolutely include a growing degree days value where data is available, ideally with a way to educate people on this system and provide them with information on the average growing degree days in their area, since it's mostly unknown to hobby/small gardeners.

Missing flash / alert section at top of layout.

I was installing Devise this morning and noticed we don't have an alert / notice section on our layout. I put one in with some

tags for now (devise requires it), but we will need to style it at some point. Leaving this issue here as a reminder.

Nothing at http://OpenFarm.cc domain

Nothing at http://OpenFarm.cc domain. Where is this deployed?