Question: Trello vs GitHub Projects

[stefanos82]

@scottybo You mentioned in another issue about covering financial expenses for services such as Trello.

What's wrong with Projects that come by default with each repository?

It's a kanban board, much like you get with Trello.

[nylen]

+1 for sticking with GitHub. Adding Trello would have a number of disadvantages:

• Fragments our data and planning further
• Expenses
• Not as easy for casual users to browse, understand, and participate

[warrior79]

It's a good idea to use GitHub Projects, IMO what matters it's the Kanban Board approach

[Mte90]

We need only to structure the repositories in a way that they are created in the right repo like for proposal, bugs, expenses etc.

[scottybo]

Happy to go with projects - never used it before (nor did I know it even exists!)

[danieltj27]

Personal opinion: keep everything under one roof as much as possible. I'd rather not have to sign up to new services or login to various different ones just to check one thing. If we keep lots of stuff under GitHub it'll make processes much easier.

[nylen]

We should also consider building our own small, custom tools based on GitHub. One example would be organizing and voting on feature proposals.

[stefanos82]

@nylen can you provide an example? Did you mean to extend GitHub in a way to meet our needs?

[nylen]

Yes. For example, say that we want to use GitHub to track features that are proposed for inclusion in the project. I think this is totally reasonable, and at first, we could just use GitHub issues and labels.

Then, when we know more about our specific needs beyond what GitHub offers, we can start building things out a bit more, without breaking the existing interactions via GitHub. In this case the workflow could look something like this:

• Create an issue for each proposed change or feature
• Assign all of these issues the same label like feature proposal
• Provide a way for community members to indicate interest in each proposal (this can be as simple and natural as counting the number of issue comments and/or emoji reactions)
• Build a read-only web UI to display feature proposals and their possible decisions, sorted by popularity. The UI will pull data from these same issues.
• Come up with some other mechanism (a specific comment or action by a committee member, perhaps) to track a decision, and indicate this in the web UI too.

Creating an initial version of a tool like this should take 5-10 hours - but I don't think we even need to go that far yet.

To me this is a better use of our resources than paying for a separate tool which then requires its own infrastructure, separate logins, etc.

[ginsterbusch]

@nylen I agree with that. Esp. when the next thing I'm going to work on is a port / partial fork of the Betatester Plugin, which in our case would have to pull in its data straight from Github. Thus if all tails at first aim toward Github - the better for me to implement this feature.

[striebwj]

We can use Fider with a sign in option of Github to allow easy access to the platform without the need of two sign ins. This allows developers on Github to access it, while also ensuring end-users (non-developers) can also easily access it.

I spent today setting it up, just need to point a domain to it then it is all good to go.

[nylen]

@striebwj I appreciate the effort, but in general I think we should be careful about adding a lot of new tools, especially before we know we have a need for them.

It's nice that Fider allows GitHub logins, but I am not crazy about fragmenting our discussion and planning even further (we already have GitHub and Slack).

[scottybo]

@nylen @striebwj

One thing I'd like to say at this juncture is that github is VERY SCARY to non-tech people. A major (if not THE major) goal of ClassicPress is to get all stakeholders involved in the conversation about the direction it takes. Forcing Mrs Jones (who has a hypothetical ClassicPress website selling hand made knitted teddies) to sign up to Github simply won't happen.

We need a friendly, welcoming and simple interface for people from all walks of life to quickly get involved with the conversation. Fider is crazy simple, and whilst I agree with your sentiment about keeping everything in one place, for now I think Fider is the optimal soluton to the problem, at least for the short term.

We've got enough on our plates with just creating the fork, and I'd prefer not to have too many offshoot coding projects when there are off-the-shelf solutions available which will work "for now".

[nylen]

Thanks for providing a way for non-devs to get involved.

We've got enough on our plates with just creating the fork

Right, another aspect of this is maintenance burden. It's one thing to have ~500 lines of PHP that are deployed the same way as our other infrastructure projects (GitHub + Forge), but it's pretty different to use and serve a Go webapp from Docker, that at the moment only one person knows how to maintain.

Every new system or tool we introduce has a long-term cost, so let's be careful about adding new stuff please.

Closing this as I think this issue has served its purpose.