void

[algorand]

void

[derbear]

Thanks for pointing this out! Our documentation is definitely lacking in various places and is not complete as it should be.

As far as I know, the README section you mentioned (https://github.com/algorand/go-algorand#project-layout) has the most accurate and up-to-date summary of the project architecture. We also have README files in package subdirectories (https://github.com/algorand/go-algorand/blob/master/ledger/README.md, https://github.com/algorand/go-algorand/blob/master/auction/README.md, https://github.com/algorand/go-algorand/blob/master/agreement/README.md) which describe parts of the code at a finer granularity.

[derbear]

@winder + @algoradam, wanted to get your opinion on whether to move, remove, or reorganize https://github.com/algorand/go-algorand/blob/master/docs/architecture.md. (My understanding is that this was part of an older README which was moved here as a partial reorganization.)

[winder]

@derbear I think that we could remove architecture.md, or move that content to the agreement README.

Perhaps cross linking those READMEs in the project layout as a breadcrumb for people browsing the project would be a better approach?

I think that the Project Layout section is the "hierarchical architecture" doc that you're looking for.

[winder]

@lazaridiscom thanks for the suggestion, I think that a document per package is a fine goal to work towards.

Closing myself, as a protest for the far too fast closed other issues.

[winder]

@lazaridiscom I'm sorry that we were not welcoming enough. Although it may not seem like it from your recent experience, our goal is to create a high quality product backed up by high quality code. It sounds like you have some strong opinions backed up by experience and we're eager to benefit from that experience. I think that you've already noticed that golang is a fairly opinionated ecosystem, in attempting to create an idiomatic project our code reflects some of those opinions. Personally, I would prefer if tests living in a separate directory like in a java application, but that isn't how things are done with go.

I would ask that you refrain from personal attacks, that's something we're unable to tolerate. I think there was some frustration from both ends of the conversation and it's truly unfortunate that we reached a communication breakdown.

In the future we'll try to be more welcoming and sorry again that you had a bad experience.

Regards to this specific item, I think that it was the most actionable of your feedback, and a great suggestion. I've created #194 to begin addressing the problem and hopefully the next developer to take a look at our code has a better experience than you did.

I'm sorry

Don't be. Just be professional.

I would ask that you refrain from personal attacks, that's something we're unable to tolerate.

And I would ask you to stop accusing me with such nonsense.

It sounds like you have some strong opinions backed up by experience and we're eager to benefit from that experience.

I come form hardware-design. the quality of electronic-devices SDK's are usually high, and this is what I'm used to.

As to the rest of your justifications, explanations etc.:

Amateurs and Mediocre give in to tool-imposed nonsense.

Professionals counter/expose this nonsense, to the benefit of the userbase. And if this means to drop a language-system, then so be it.

Decide what you are.

I'm out here, terribly disappointed by this MIT rooted project. I mean, you sound/feel like a typical low-quality Ethereum project. And I really can't take such projects anymore, discussing things to death, even the most fundamental things.

we're eager to benefit from that experience.

Just saw this.

Again: don't close issues that fast, and be aware that contributors here can reopen issues only if closed by themselves.