- Voting and privileges will be “different”
- No reputation nor badges
- No separate chat, and comments will be “different”
These details seem to me to be add-ons or frills compared to the basic functionality.
IMO the “basic functionality” is support for the following types of data/item …
- Users (name, gravatar)
- Topics (each with a title, text, author, tags, date, and answers)
- Answers (each with a topic, author, date)
- Tags (title, short description, long description, associated topics)
… where “support for” means implementing the software which lets you do just the following CRUD-like operations, for each of the types of data listed above:
- List all (show a list of item summaries with sorting, filtering, and paging)
- View one item in detail (e.g. selected from a list)
- Create a new item, and edit an existing item
- Navigation between the different types of item (hyperlinks within the page, and in the page margins and/or in the navigation bar at the top of the page)
Perhaps implementing that can be a first sprint. It would require you to define and implement:
- The front-end and the the back-end
- The API between and/or within the two (including URLs and data formats)
- The run-time environment of each
- Code to which additional features can be added (see Gall’s law)
Well it’s open-source, right? So …
But “planning to customise” seems wrong to me at a very early stage – it’s saying, “I can’t specify even one design, so please write the software so that it’s configurable so that other people can implement anything.”
As a software developer I have to implement something in particular, without a specification then I can’t start – or I can start, but only by starting without you.
Instead of their being no specification, what I would want (as a coder) is either one design specification (“please implement this design spec”) – or two specifications (“write the software such that it can satisfies either or both these specified designs”).
That’s why I cloned the SO UI when I implemented the “basic functionality” defined above – because I needed a/any design specification in order to write code (i.e. to implement something in particular) – I can implement i.e. code a front end or a back end but “I’m not a UI person” i.e. a designer, so.
There are several APIs, at different layers/levels of the system. One of them is simply the set of URLs between the front end and the back-end – e.g. …
/questions?tab=active&page=2 – to get some of the latest topics
/questions/[id]/[title] – the URL or “route” to get a specific topic
… which is the interface between the front and back ends (assuming a REST-like API).
Then you need to specify the format of the data.
That sounds old-school – I guess that “schema” is a consequence of using the MS .NET stack and SQL.
When I did my prototype I defined the data using TypeScript – i.e. a set of TypeScript interfaces to define the types and the data members of each type – https://github.com/cwellsx/react-forum/tree/master/src/data
That might looks trivial but it’s what/all a front-end needs – the front-end might be entirely uninterested in any database-specific implementation/schema.