Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion] Improving our development process #4396

Closed
ErisDS opened this issue Nov 4, 2014 · 13 comments
Closed

[Discussion] Improving our development process #4396

ErisDS opened this issue Nov 4, 2014 · 13 comments

Comments

@ErisDS
Copy link
Member

ErisDS commented Nov 4, 2014

Lately, we've been trying out new things with our development process in order to get a bit more fluid (agile) and move towards releasing little-and-often instead of dropping great big releases every few months. Some of this has gone really well (we're releasing more stuff faster) and some of it hasn't necessarily (I don't feel like the process is particularly clear). So I'd like to get some feedback on ideas on how to get better at doing what we do.

I have the following goals:

  • Make sure the what and why of our short and mid-terms priorities are clear
  • Ensure that our current contributors are happy that our processes are working well
  • Encourage more new contributors to get stuck in & make it easier for them to do so

To aid the conversation, below is a little bit of an overview of the way we work:


  • We have a public meeting in the #ghost IRC channel on Tuesday every week at 5:30pm London time, to discuss progress and what's next.
  • Our public roadmap is on Trello and is 100% feature-focused. The Backlog column is a list of things we want to do one day (for v1.0), Next is for things that are ready to work on and we want to get into a release, and In Progress is for things which are actively being worked on.
  • We have 3 GitHub milestones we use as issue backlogs: Current which contains the 'top 10' priority items for the next release, Next which contains everything else that is ready to be picked up and worked on, and Future which contains other tasks we're tracking but that are blocked on something else.
  • The roadmap and backlog are curated by those with admin access (Ghost Foundation + Core Team members), but mostly by @JohnONolan and me, based on a mix of user demand and what is technically possible / ready to implement.
  • We don't really have a long term plan of when things should ship, just a general idea of what we need to do to get to 1.0
  • We have a blocker tag which we use when we start thinking about doing a release for anything preventing a release going out, or anything super-duper high priority to get fixed.
  • We have a beginner tag to mark issues suitable for developers who are new to the Ghost codebase
  • We have a help wanted tag to mark issues we'd love someone to come and get involved with
  • We release whenever we feel ready, and I usually give an indication of when that will be in the dev meeting & blog post (currently I'm still the only person able to do this).

Some ideas to get us started:

  • Overhaul the contribution guidelines with a TL;DR, more links to wiki pages on process and how to get started (I've started this a couple of times and not been happy with the results.)
  • Overhaul the Ghost wiki to focus (even) more on being a contributors/developers manual
  • Figure out the best approach to documenting the code base and push forward with making it a reality
  • Start publishing job spec type listings on Ghost.org advertising for contributors to certain areas (like OAuth, Search, i18n)
  • Revitalise the wiki Roadmap page to have more detail about high priority items which are not features so are not on the public roadmap, but are blocking features (like permission migrations)
  • Have a 'Road to 0.6' type write up either in the roadmap or in an Epic issue itemising the bare minimum features / refactors / bugs / etc we'd like to get in before we're ready to call Ghost 0.6, their dependencies and any other relevant info
  • Do a big write up of the long term plan for Ghost 1.0

I'm very, VERY interested to hear feedback and new ideas. This is going to be pretty much all personal opinion, so in the interest of keeping the discussion positive, productive and awesome, please try to qualify your ideas and concerns by telling us about your workflow and how the processes do or don't fit in.

@ErisDS ErisDS added this to the Next Backlog milestone Nov 4, 2014
@felixrieseberg
Copy link
Member

I'd like to point out that contributing under the current regime is pretty rewarding - the community we have hear is nice, helpful and in general pretty awesome. I personally am having a lot of fun doing it. Telling friends about it, I keep hearing one thing though: "Why would I code for free for a company?".

I'm very much aware of how this statement is invalid and requires a "wait, that's not the point [...]", but we might be able to attract more people by making it more obvious that Ghost isn't just an open code base, but truly MIT OSS. Without having a decent overarching solution, the fact that ghost.org doesn't have a link (I could find) to ghost.org/download might be one of the contributing factors.

@novaugust
Copy link
Contributor

I try to use the beginner tag whenever I can, but help wanted isn't something I've ever put in. I understood it as "We have no one who understand this, please, someone, come take us by the hand!"
If it's more of a "here's an issue where it isn't clear who's going to be working on it", then hell, I'd probably start overusing it.
So what I'm getting at is, what exactly are the different use cases between beginner and help wanted? Is help wanted the rectangle to beginner's square?

@nuclearpengy
Copy link

  • The Trello board is a great overall view of what's coming. I like it.
  • I think it would be great switching chat/meetings to Slack if that's possible - I see Wordpress have recently done this. I think this opens things up to a lot of users who would like to get involved but aren't as in-tune with the IRC vibe. Slack is just simple and easy.
  • with regards to "job spec" on Ghost.org, how about dynamically pulling through all issues with a specific tag(not sure if that's possible) then people could see all "beginner" issues "un-assigned" as a way of encouraging people to get involved. (as an example)
  • with regards to labels - it might be good to have a "guide to labels" in the wiki, similar to the way that the trello board has an explanation of what the colours mean.

@brandonvanha
Copy link

When I started to look into Ghost for the first time the other day I found myself going back and forth between the development and business sides by hopping through links that at times seemed fragmented and overwhelmed and not sure at first If the information was for developers or end users.

For example,
https://github.com/TryGhost/Ghost/wiki/%5BWIP%5D-API-Documentation
https://github.com/TryGhost/Ghost-Vagrant
http://themes.ghost.org/
https://ghost.org/download/
https://github.com/TryGhost/Ghost/blob/master/CONTRIBUTING.md#working-on-ghost-core
https://ghost.org/about/contribute/
https://ghost.org/forum/
http://dev.ghost.org/
http://support.ghost.org/installation/
etc.

I think it would be great to see Ghost divided into two domains of information: one for developers and one for end users/customers.

For example,


  1. Use the ghost.io domain for development-related information/documents that’s geared towards developers.
    • api.ghost.io (or ghost.io/api)
    • apps.ghost.io
    • themes.ghost.io
    • etc.
  2. Use the ghost.org domain strictly for Ghost(Pro) and business-related services (e.g. marketplace for themes and apps, etc.) that's geared towards end users/customers.

It might help with getting new contributions if new developers have easy access to information by accessing one domain that’s focused for them.

The public roadmap on Trello looks great!

Just my 2 cents. 👍

p.s. I do hope to contribute something (whether it’ll be testing or trying out beginner’s issue) once I’m more familiar with the inner workings of Ghost and its dependencies. 😄

@javorszky
Copy link
Contributor

Personally I wouldn't move IRC to Slack. While WordPress and #nomads have done it, and both have 600+ users in there, it's unmanageable. Slack is awesome for small teams, but for large groups it becomes VERY difficult. I muted notifications from the WP and nomads teams, which just means I don't even check them.

Also, IRC is easier for users to hop in if they have a question.

@nuclearpengy
Copy link

Thanks @javorszky. I haven't got experience in big groups only groups of ±10 so I can't argue with you there. :)

Nice thought, but if it's not feasible then it's one of those things.

I guess my comment was in part driven by my lack of personal IRC adoption, Guess I just haven't used it enough.

@javorszky
Copy link
Contributor

For anyone struggling to find an IRC client: www.irccloud.com

Just... do that. It replaced textual overnight for me. :)

@nuclearpengy
Copy link

:-)

ErisDS added a commit to ErisDS/Ghost that referenced this issue Nov 13, 2014
ref TryGhost#4396

- adds a TLDR, updates links throughout & improves language
@Hell0wor1d
Copy link

Very nice discussion. 👍

@raulfelix
Copy link

In terms of process I have often worked within variations of agile. I have used Jira as an issue tracking tool many times and one of the great things about it is that it really easy to see tasks that are in progress.

I have been trying to get started/involved and managed to find out about the beginner label being used through reading the getting started guide but where I have spent a lot of time confused now is knowing if an issue has been started on by someone. Perhaps a rule that you must assign the issue to yourself once you begin on it is in store to clearly show progress? An example of this would be this issue #4596

@novaugust
Copy link
Contributor

The problem with assigning people is, they have to be a member of the
TryGhost organization. We can't assign issues to just anyone who comes
along, unfortunately :/

On Wed, Jan 28, 2015 at 6:15 PM, Raúl Felix Carrizo <
notifications@github.com> wrote:

In terms of process I have often worked within variations of agile. I have
used Jira as an issue tracking tool many times and one of the great things
about it is that it really easy to see tasks that are in progress.

I have been trying to get started/involved and managed to find out about
the beginner label being used through reading the getting started guide but
where I have spent a lot of time confused now is knowing if an issue has
been started on by someone. Perhaps a rule that you must assign the
issue to yourself once you begin on it is in store to clearly show
progress? An example of this would be this issue #4596
#4596


Reply to this email directly or view it on GitHub
#4396 (comment).

@raulfelix
Copy link

Ohhh right... of course. It then becomes a management issue for someone then.

@ErisDS ErisDS modified the milestone: Next Backlog Oct 9, 2015
@ErisDS
Copy link
Member Author

ErisDS commented Oct 9, 2015

I'm gonna close this now as feedback has dried up. I'm working on cleaning up the issue list, using the tags beginner, fix wanted and in progress to try to make it easier to find stuff that can be worked on and closing all the issues which have been around and stuck for ages.

We have since moved our community from IRC to slack and there you can find both a #dev channel for discussing core development issues, including getting help with contributing and also a #help channel for general Ghost issues. There's also an #i18n channel for discussing that project and a #themes channel for sharing themes and talking about theme development.

I'm always interested in feedback on how we can improve the contributor process so if anyone has ideas please post here or come chat in slack!

@ErisDS ErisDS closed this as completed Oct 9, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants