Discussion and Planning - SigmaChiDeltaPhi/site GitHub Wiki

#Overview

##Organization and Logistics

With a complex project like this, it would be good idea to record and clarify different tasks and responsibilities we'll need to keep track of.

Goals and Guidelines

This might be a good place/time to brainstorm a bit on some of the less "physical" aspects of the project. We need to know where we're going, and how/when we're going to get there, so we may want to brainstorm somethings before getting too into the actual building. For example:

  • What's the best way to communicate? Should we have various methods for different topics/tasks, or can it all be managed via email?
  • Timeline/Roadmap. How do we want to scope this project? Do we have an idea of when we'd like to have an MVP/public beta version ready? What constitutes a MVP/how do we decide when the site is ready for the public?
  • How formal/structured do we want our process to be? More structure (concrete sprints, standard deployment windows, strict code review, etc.) means we might be more likely to stay on track and keep this project maintainable, but they add overhead. No/little structure (work on whatever/whenever, push/deploy whenever, etc) makes contributing easy, but also decreases maintainability. What's the right balance to take?

####Communication For general chat and updates, we might want to take a look at Slack. This should allow us to keep a log of what's gone on. We can also integrate it into our testing/build/deployment process if we want. I've set up: https://sigmachi.slack.com/ for us to test out.

Sub-products/Modules and Roles

Ideally this site will serve not only as a basic informational page, but will be a robust solution that encapsulates useful functions/features for the chapter. As such, it will most likely be made up of a number of modules. Additionally, developing, deploying and maintaining the project incorporates several external/supporting services. Needless to say, this project could be quite complex. To avoid confusion, it might make sense to have specifc people act as the product/service "owner" for the various parts of the project.

Some potential sub-products/modules are:

#####The Site: I take this to mean the basic, informational/promotional website we're creating. At a minimum, this would be considered the "core" product, achieving functional parity with the existing site. Benefit/Goal: Listed for completeness sake. If we use this model, each piece needs an owner

#####Database: Big Tree requires a database, and I imagine we might have a few other uses for a database as well. For continuity and clarity, we may want to designate someone to act as the "go to guy," with the final say on database matters. On the other hand, if reliance on the database is minimal, it might be possible to "set it and forget it" and allow us to proceed without a lot of actual management after initial setup. Benefit/Goal: Completeness. Additional depends on the scope/needs of the project

Travis: Tables are flexible, but BigTree reserves the following columns:

  • "id" (Primary Key) - INT - Primary key of every table.
  • "approved" - CHAR(2) - Used with the view action (getApproved, getUnapproved)
  • "archived" - CHAR(2) - Used with the archive action (getArchived, getUnarchived)
  • "featured" - CHAR(2) - Used with the featured action (getFeatured)
  • "position" - INT(11) - Used with draggable views (getAllPositioned) BigTree prefixes "bigtree_" to its internal table names. We might consider prefixing some string to custom table names (and those created with module designer).

#####Ops/IT: The actual webhost (our production environment), as well as our development environments. Working with various virtual and physical environments can make it easy for things to get out of sync, which can introduce problems with building/integrating/deploying code. Benefit/Goal: Keep our environments standardized and in sync with production

#####QA: Not to say that only one person should be writing tests, but depending on our workflow, we may want someone to act as the shot-caller for testing and integration. Whether they are the ones to approve pull requests, or decide when/what to release can be fleshed out later. Benefit/Goal: Keep code-base clean, ready to deploy. Help to mitigate conflicts when merging

#####Documentation: The wiki, issue tracker, and other sources of internal information. While everyone is (hopefully) contributing to this, it might be wise to have a designated curator. Benefit/Goal: To preserve style/structure, and avoid redundancy/exclusion of information

##Style Guide