Here’s the funding proposal from the UI corner of Neos 
Alexander, some answers to your documentation topic:
The link is already fixed. The draft articles are mainly parts of the documentation which were before readthedocs drafts for many years. While better than ever, our docs still need some love.
While references should be in the docs, I think all documentation should be in Neos. Writing text is ok in a git versioned system, but images, videos, … all that is really hard and error-prone in rST. There were a lot of formatting bugs in the old documentation. Modern easy to read content with links, images, and maybe even interactive content is easier to create in Neos.
The publish workflow can be drastically improved, a form on the docs website could automatically create a new user with a separate review workspace. As soon as the editor published his changes we already get an email and can review and publish those changes. So there would be the same amount of manual steps as a git merge.
I started a Guide Tour a long time ago, but than the docs project happend. If anyone wants to work on it: https://github.com/rolandschuetz/neos-guidedtour
@baachi The documentation on readthedocs will be gone after the next release, docs.neos.io is the new place.
1 Like
Hey Roland, thanks for chiming in.
What I mainly fear is that the documentation will too easily be outdated. Especially the parts that go into implementation details. We already have this issue as is and I think completely having everything in a Neos instance will make it even worse. Optimally I think that the most basic, low-level and technical documentation about features should live in git and side-by-side with the actual code. Even now, with the docs in git but seperated by an abritrary folder structure leads to documents often not reflecting the actual state of affairs, code examples getting outdated etc.
From a maintenance PoV every new feature or change of existing feature should always be delivered together with proper documentation describing it. From my experience though, humans tend to be bad with keeping separated processes in sync manually.
My wish would be to somehow connect both worlds, have a redacted and enriched documentation in Neos which pulls in parts from a living documentation inside git. However this could be achieved is up to be discussed (may be a node type that fetches an rST/md file from git and renders it?), but I think this would improve things a lot.
Also, what I’m not sure how it is handled currently: what about docs for different versions of the system? e.g. old ui/new ui, future old CR/new ES CR? If there is a solution on how to deal with that, is it documented?
As said, I totally love the efforts you and the others did up to now with docs.neos.io, it is so so much better than before. I still think there are a couple of things we could improve further to make sure the documentation will at minimum keep at this level in the long run and hence why we should think about sustainable processes, that are as tidy and straightforward as possible. So I’d love to see some budget to get this rolling!
The publish workflow can be drastically improved, a form on the docs website could automatically create a new user with a separate review workspace. As soon as the editor published his changes we already get an email and can review and publish those changes. So there would be the same amount of manual steps as a git merge.
Is this already in place? If not, that would be another great topic for getting done with a budget
I started a Guide Tour a long time ago, but than the docs project happend. If anyone wants to work on it: https://github.com/rolandschuetz/neos-guidedtour
Looks like some solid base! 
That would indeed be super nice - basically just one running instance (which the neos foundation could sponsor?), that automatically deploys the latest stable version, gets reset every 24 hours and has a nice demo site that highlights the core features and USPs. For starters, this could just be the https://github.com/neos/Neos.Demo and maybe that one can be improved a bit through this new use case.
Experience from the last years shows that having docs in git does not necessarily lead to updated and well-maintained documentation. There was a lot of faulty, bad or not recommended documentation, e.g. extending or adopting the Neos.NodeTypes:Page for implementing all your NodeTypes.
I agree that documentation MUST become part of the release process. I mentioned that already a few times in the Slack #team and on the conference sprint. Features should ONLY be allowed to be merged after proper documentation. If having it on git helps this, reading some rST/md file in Neos is simple and can be done.
So far we are still struggling to get the most up-to-date documentation perfect, so the focus isn’t yet on different versions of Neos. In the manual and documentation is should be handled by highlighted boxes pointing out differences between versions. In examples, we want to show different code on the same page, e.g. https://docs.neos.io/cms/tutorials/changing-the-body-class-with-a-condition
Keep in mind, the actual reference still stays on ReadTheDocs and are versioned.
The publish workflow currently requires me manually creating users. If someone wants to take care of automating that, I’d love it.
While there is a demand for improving the docs, I won’t be the lead on this proposal. Getting it to this level cost me a lot of energy, and honestly, I started to hate the docs a bit especially after the last two full holiday-weeks just writing docs and getting it finally finished.
I would still love to work in that area, so here are two budget proposals:
1 Like
@tobias and others:
- Where can I find information about hourly rate used for giving [estimated times] * [hourly rate] ?
Find my funding request for a “Welcome” / “Introduction” distribution
Find my funding request for “Split doctrine integrations (validation etc) from Neos.Flow and move to own persistence package”
Find my funding request for "[Flow Light] Routing: Move ObjectPathMapping to a cache
Find my funding request for “[Flow Light] Resource management: Create a resource storage that doesn’t need database”
1 Like
Hello Soren,
what would be the main advantage of Flow Light. 22k of a total budget of 28k is a really big investment, considering that we will need money for the CR rewrite. How would this help Neos grow?
Thanks for reading my funding requests. Always exciting to enter “new terriroties” (funding request for open source work) and get feedback on such 
FYI: I do not use Neos CMS in my active work, but have been a part of the Phoenix/Flow/Neos community since the project/rewrite started. I do use the Flow framework in my everyday non-cms based work tasks.
- Lower the entry barrier
- Usable for a larger number of projects that need small HTTP framework with a (M)VC stack as requirement
- (Even) easier extensibility
And other points covered in the thread linked to, from when the proposal was originally presented.
Note, that it’s 22k for all package. The splitting of Doctrine is 15k. The others two are follow up tasks that will have to be done anyway. But with funding stuff floats easier, like most things here in life
The “CR Rewrite” is not more special than any other funding request - it’s part of the same voting process and has “no benefits” that secures it any funding.
You mean “Neos” as a brand or “Neos” as the CMS platform? For the “Flow” product of the Neos community I listed a few in the top of this response. For “Neos” as the “CMS Platform” build on Flow, it’s a way to get a larger userbase for the Framework and hence a larger community to contribute to it.
I think Flow itself won’t be able to grow the user base substantially. Laravel has a great framework, really good documentation, super readable source code, and a big ecosystem of tutorials, packages and tooling. Flow will not be able to effectively compete here.
While Flow is a good framework, I think the USP and the driving force is Neos. You are right, CR is a normal funding request. For me it’s much more important.
Just my two cents.
1 Like
Just so we are clear: Neos is the brand/organization name. Neos CMS is a product build on top of the Neos Flow Framework. No Flow, No CMS.
Not taking care of Neos Flow is like not taking care of your legs as long as your arms work.
And for me - not using Neos CMS and the CR - the Neos Flow Framework is more important That’s why i submitted my proposals based on what I’ve seen and tested in the wild.
We are many different people seeing and using Neos. And I don’t find it fair to shoot down funding requests here in the general thread. Feel free to ask questions in the threads that can shed some light on the topics. I will happily respond to any questions posted on the funding requests
I’m not shutting down anything. I did not remove nor close your funding request. I wrote my opinion (“For me it’s much more important”).
And yes, ever time I used “Neos” in my previous post I’m referring to “Neos CMS”. I think that was clear out of the context.
It’s totally fine that you did your funding requests and as always the voting will decide. Might be that many people think it’s the most important part.
@sorenmalling Thanks a lot for putting all the effort into the really elaborate and thought out funding requests.
I agree that we should refrain from criticizing funding requests in this thread.
Of course we should be able to challenge requests in their respective threads (or by asking the author directly) but IMO the main purpose of the budget voting is to find our priorities – if you don’t agree with a request, just don’t vote for it.
4 Likes
Hey,
my funding request is not targeting the core directly, but one of the 3rd party packages we take care of:
Funding request: Support An index per language and Elasticsearch 6/7
2 Likes
@tobias One thing I don’t understand: According to https://neosfunding.sandstorm.de/de/transparency.html, there should be much more in the piggy bank. Am I correct to assume that the spendings are not up-to-date?
hey @sorenmalling, great question! We used 100€/h in the past. This allows us to have comparable proposals
yes, they are totally outdated and I feel really bad for showing that page… I currently don’t have the time within our team to automate that further, because a lot of manual work is currently required to keep that page up to date.
And there is a weird difference in the numbers, that I haven’t taken the time yet to track down.
So thinking about this as I write this response, it’s probably better to take the wrong information down…
2 Likes
thanks for the ping! I’ll create the Konsensierung now