Create Tailwind development environment starter as proposal, beginning to implement the current design with page sections for the homepage

[victorkane]

Wireframe Example 1. A proposal

Working on branch starter-tw-npm.

• Review current design
• Select header, first section and footer tailwind components
• Implement header
• Implement footer
• Implement first section
• Present this branch for project review

The implementation should be committed via atomic commits, so that each step of the process can be understood coherently.

[0cjs]

BTW, I'd probably stick this in a TODO.md file in the repo; that has the advantage in keeping the info in "our" information, rather than a separate GitHub proprietary database that doesn't travel with the repo. That said, I'm not too fussed about this.

And, "atomic commits, so that each step of the process can be understood coherently," yes! If the commits tell a story as you read through them that is a fantastic aid to communication amongst developers!

[victorkane]

In response to excellent suggestion, created kanban folder, with subdirs:

kanban folder	purpose
1-new	new "creative" suggestions of all kinds and priorities
2-todo	prioritized backlog
3-wip	what we're working on right now, kept to a minimum
4-mvp01	tasks completed for current mvp

All folders to be populated with .md files, which can be moved to different folders according to their kanban state. We'll keep this as simple as possible.

Great, no more github issues, which can be downloaded via the Github API, but are not accessible via repo, like the Github Wiki (which we'll only use if necessary)

[0cjs]

I don't think it's ever necessary to use the Wiki. While that at least is in a repo that can be cloned and moved elsewhere, the display is substantially the same as the display of Markdown files in the main repo. For an example of a "wiki" done entirely in a main repo, you can have a look at 0cjs/sedoc. Pages such as lang/python/README demonstrate linking between pages and the CMake pages demonstrate use of a "menu bar" for switching between related pages.

Keeping the documentation in the main repo has the advantage that documentation changes can be in the same commit as their related code changes, ensuring that documentation is always in sync with whatever version of the system someone is looking at and also making review easier.

[victorkane]

Keeping the documentation in the main repo has the advantage that documentation changes can be in the same commit as their related code changes, ensuring that documentation is always in sync with whatever version of the system someone is looking at and also making review easier.

Completely untrue for teams. People are working in different branches, it's a pain for either 1) multiple copies of the docs to exist in all branches (impossible to maintain); 2) maintain a separate docs branch (as is done with GitHub pages), in which the code and the docs are necessarily in separate branches.

Separate project issue tracking software should be used if we don't want to use Github issues.

[0cjs]

I get the impression that you're thinking of the documentation as separate from the code in some way. Certainly we do not want a separate "docs" branch. But having documentation changes on development branches is no different from having code changes on development branches: the process of change, review, etc. is exactly the same for both. I have extensive experience working with development branches and do not find them at all "impossible to maintain," so if you anybody encounters difficulty with this we can get together and I can show you how to solve whatever problems you're having.

Possibly this is simply one of those things where you need to see it done before you come to a real understanding of how it can work.

[victorkane]

Insofar as documentation (which should certainly exist separate from the code also for the organization as a whole and for onboarding in general) is concerned, yes, we can have documentation in code. But we're not talking about documentation at all. We're talking about agile issue tracking, which involves CONVERSATION. If agile development is Card, Conversation, Confirmation (user story, issue tracking conversation among various members of the team, testing), there the problems develop with what you are proposing. For one person doing it alone, it's feasible, but it is impossible to commit conversation (statement of problems, solutions, getting unstuck, reporting issues and reporting solutions, etc, etc.).

[0cjs]

I don't see why documentation must not be kept in the same repo and on the same branches as the code. What's the problem that this creates? It's certainly not that it's harder to read; GitHub displays Markdown files essentially the same way whether they are in the code branches, separate branches, or a completely different repo.

As for the user stories, again, keeping them with the code helps keep things synchronised; the stories can be updated in the same commits that make the changes that cause the stories to need to be updated.