iamtrask / DEPRECATED

DEPRECATED - do not use!!!
Apache License 2.0
349 stars 48 forks source link

Documentation Structure of Projects #8

Open samsontmr opened 6 years ago

samsontmr commented 6 years ago

For all the projects, what do you guys think of categorizing their documentation into 2 types: "Developer/Technical" (setting up dev environment, API docs, etc.) and "Product" (roadmaps, user stories), and keeping "Developer" docs in the project repo itself and "Product" docs in this repo? Or should we just have each project repo contain everything about the project?

I feel that having the language agnostic docs in this repo would help us deal with the issue of polyglot development more gracefully :)

anoff commented 6 years ago

That's a very tough thing to do correctly, glad you bring the discussion up. I agree that technical docs should stay with the repo - pretty sure that's a given. However I think it is important to keep some sort of "planning" with the invidivual component - and therefore in the respective repository. When I thought about it I came up with the term featuremap to explicitly state the difference to the project roadmap. The idea behind a component individual featuremap is to allow ideation within a component. If we overprocess this by having all ideas submitted to a general repository you might kill meritocracy

The challenge is that OSS works great on a single project/component. In our case we have to somehow align multiple components that are isolated for developers due to barriers on the technical side (different languages) as well as domain (crypto, blockchain, AI..). So we basically have N small projects that should be able to live out meritocracy.

In my head the core contributor(s) of each component would be part of generating the OpenMined roadmap and decide on milestones.

Edit Oh I forgot the other side: The big challenge however is to keep component development aligned and even more important to make sure someone within the component feels responsible to solve issues coming up for a Milestone. Here classic enterprise approach from the 90s is to top down plan everything. That would mean plan all components in a central repository and distribute work. It easily solves the issue - except today everything has complexity in it which is why classic project management fails. I think the OpenMined platform is more complex than most products out there. We need to find a middle ground between both.

Note: That's a process that we more or less live at work - except meritocracy 🙈

samsontmr commented 6 years ago

Great points raised here. First thing that came to my mind was feedforward (ideation) and backpropagation (defining issues) :P