Planning post #1

[quivo]

Edit: I'm now moving the tasks in this post to this Trello board for better organization/assignment.

Here's the deal. Absent the sudden and miraculous addition of Sally Jobs, Coder Extraordinnaire, to our contributor team, what we are is a bunch of enthusiastic mostly-amateurs and busy pros with moderate to no coding experience, and varying amounts of free time we're willing to devote to this.

Which, considering the example of the AO3, is worrying at best ("we don't know what we're doing either! How do we avoid falling down the same hole??") and terrifying at worst ("these people I've signed up to work with could all turn out to be insane fandom wankers!!! D:. Also everyone will see my/our terrible code and laugh").

So I figure we can all promise ourselves a few things, to keep this from turning from a fun side project into a demotivating, depressing, and possibly hilariously wanky time-suck:

1. Speak up.

   • As little experience as I have in project management leadership, I have enough experience muddling through shitty situations to know that feeling unable to speak up or voice your concerns is the number one indicator of bad things to come. If you have an issue, whether it's with project results, task assignment, or with another contributor, don't sit and stew about it (or at least, don't do it for too long). Talk to whoever you're partnered with, bring it up in chat, or reach out to me.

2. Fun first...

   • If we try to do this thing out of obligation, it is going to go nowhere fast. If, when you were originally reaching out to me, you volunteered to do stuff you're not actually that interested in, please speak up asap. Same goes for volunteering for stuff you originally thought you wouldn't be interested in, or for giving up a task that is driving you mad.
     

3. ...but the boring shit does have to get done.

   • There will most likely be scut work that few of us or none of us have much interest in doing, but is still essential to the ongoing functioning of the project. The faster we get the boring shit done, the sooner we all can get back to the good stuff.

4. Get it done, or drop it.

   • By 'it', I mean whatever task you've been assigned, or you've taken ownership of. If you don't think you'll be able to finish something, or you need to take a break, or other obligations are chewing your time, drop me and your task partner a line about it.
     If you have a real life crisis or some other situation that requires your full attention, address it first. Drop us a line when you have the bandwidth to do so, and come back to dive in when you can.

To sum up, the overarching rule: let us all try to treat each other with kindness and respect. If we get as far as doing regular releases on github, I'll want to adopt something similar to this code of conduct as a baseline for governing how project contributors interact.

Roadmap

Since it's just going to be a handful of us working on this initially, I don't think it'd be helpful to commit to anything more strenuous than a roughly quarterly public release. 'Sometime in June' sounds good enough to me for a point where we absolutely want to have something functional up on github, though it'll most likely be a rough development release (0.x.x). Release versioning will use semantic versioning; to familiarize yourself with that or refresh your memory of what that entails, check this out.

We don't have any data on how long it'll take us to complete tasks, so any dates or timelines for when we'd like to have work completed will be estimates for the time being. That said, here's how I think we should spend the next few weeks:

Format:

• Task name -- assigned, contributor(s), (estimated time to complete task)
  
  • Task description.

---

Note: Tasks listed in rough order I think they should be completed. Will change to accommodate our needs and schedule as necessary.

• Choosing tech stack -- quivo, curiouskitten, dlh, zinnia_au, theliterator, (1 week)
  I've given this a generous estimate because we can complete some of the other tasks without having made a final decision on every point here.

  • For the framework:
    • Choice is out of rails, laravel and django. Have discounted the big JS frameworks on account of them being mostly aimed at producing single-page applications, which we definitely Do Not Want.
    • I've installed rails, laravel and django, and will be noodling around in them to see which is the most fun to work with.
  • For the database:
    
    • PostgreSQL is it. Robust, widely supported, will work for larger sites no problem. Debating vs going with 9.6 or 10.
  • For the server:
    
    • nginx chosen because why not.
  • For frontend:
    
    • HTML5
    • No preference on CSS preprocessor
    • Templating language will depend some on framework
    • JS library may depend on framework?
  • For documentation:
    
    • Have been working in markdown for most site-related notes and posts I've been making, but may need to decide on standard processor for it
    • Will initially be just on our github repo wiki. Can upgrade to something more structured later, or even just spin up something for doc management on our chosen framework
  • Search? Caching?
    • Most likely going to go with Elastic Search and Redis, but until we've started work on the search and caching plugins, we can just ignore this.

• Learning enough lang to be useful -- quivo, curiouskitten, (2 weeks / ongoing)

  • What it says on the tin. lang a placeholder since we haven't yet chosen a framework, will be replaced when we do. Time estimate made generous in assumption that we will somewhat be learning as we work on tasks

• Making detailed spec for barebones version 0.1.0 -- zinnia_au (if you're up for it!), (1-2 days)

  • Step-by-step breakdown of desired workflow, plus any additional technical details we want to include (HTTPS everywhere, minimally mobile-friendly design, etc)

• Planning out the details of the models, views and controllers required to hit spec for 0.1.0 -- quivo, maybe zinnia_au, (1-2 days)

  • What it says on the tin.

• Producing friendly, easy-to-understand copy for 0.1.0 site admin panel -- theliterator, dlh, (2-3 days)

  • Should be the small amounts of text that will go on the admin panel and the login page/popup. This may end up being done by whoever's coding the html & css, at least initially, but it can also fall to people with experience in a) how to explain stuff clearly and b) what users are likely to find confusing and/or overwhelming.

• Synchronizing test stack -- quivo, zinnia_au, curiouskitten, (1-2 days)

  • Getting set up on github with a repo that contains the framework + optional modules we're going to build on for 0.1.0. Setting up dev environment and making sure it works.

• Producing rough archive html & css -- quivo, zinnia_au, curiouskitten, (2-3 days)

  • This task can be split down to individual pages if needed. Ideally, these will be minimally responsive / reflowable in a way that looks okay on mobile.

• Producing and testing controllers -- quivo, zinnia_au, (2 weeks)

  • Coding, testing and debugging controllers necessary to make 0.1.0 work as specced.

• Producing and testing models -- quivo, zinnia_au, (2 weeks)

  • How we go about this will depend on chosen framework. Basic idea is to make sure database structure works properly for what we want from 0.1.0.

• Producing and testing views -- quivo, zinnia_au, curiouskitten, (2 weeks)

  • Converting previously produced rough html & css files to views
  • Testing that views look and function as required, to both authenticated and unauthenticated users

Administrivia

If we're going to work together on tasks, we need to know how and when to get in contact with each other. So, for this first round of task assignment, I'd like you to include the following, in addition to task acceptance/rejection notes:

<em>My time zone:</em> (time zone) 
<em>Hours I'm usually available to chat:</em> (hours) 
<em>Preferred communication method:</em> discord & or 
email & discord / dreamwidth PMs 
<em>How long it'll usually take me to respond:</em> 
via discord, three weeks; via email, a couple centuries

<em>Heads up:</em> (going to be extra busy at work 
this week? Need to take care of IRL stuff, or just 
need a break? Here's where you let us know) 
<em>Current tasks I'm accepting:</em> (task; task, 
reason why if needed) 
<em>Current task I'm rejecting:</em> (task, short 
reason why; other task, reason why)

When you comment, feel free to include any questions or concerns you have re this post. Think there's a task we should be working on in the next couple weeks, and it's not on the list above? Think one of my tasks is poorly stated/described, or needs a change in estimate? Let me know, so we can figure out what needs to be changed, and I can revise the post.

For now, I think I can commit to churning these task assignment lists out every week. They will be posted and revised on Dreamwidth for the first couple weeks; at some point we are going to have to pick a way to coordinate the project management side of things, but that needn't be right this minute.