Hey Neos team members and community. We currently have around 18k€ in our piggy bank with approx. 10k€ coming in until the end of the year. So 28k€ to be spent.
As every year it would be a pity to let too much of that go to taxes…
Things I’d like to have prioritized/funded to get them done:
improve documentation further. The last effort was awesome, but there’s still some things to improve! For example there are a couple of “Draft” articles and e.g. https://docs.neos.io/cms/manual/using-neos-with-php-flow leads to a “page not found”, more videos (even more introductory than the current ones)…
create a process for the new documentation (docs.neos.io) that is sustainable/workable for every contributor. Currently AFAIS it involves reaching out for an account, going into the Neos backend and writing the documentation there, asking for a review, until it is published eventually. This is a lot of manual steps and jumps to make and most importantly, it’s fully disconnected from the development cycle. While this has benefits (make writing documents accessible to non-devs), it likewise currently has the drawback of making writing docs less accessible to devs. Optimally, both would be possible. So IMO we need a process where one can just write some md/rST that is checked into the code together with a new feature to explain it on a very basic/low level, which then gets automatically fetched and rendered in the existing docs.neos.io side by side with manually written docs. This base documentation can then be enriched with a manual written page, that references back to the git versioned feature documentation.
invest some time/fund into improving our operations processes - namely automated testing, code quality assurance and release management. While this currently “works” thanks to the awesome work of a few, it is still a bit fragile. A bunch of the TODOs is already tracked under https://github.com/neos/release-process/issues
The upmerging process could be improved and half-automated, so that anyone can at least start an upmerge process with a button click and that requires review/intervention only on merge conflicts. The process of releasing a (at least patch-level) version, could be more or less fully automated, maybe only requiring a final “approve” review (and adjust) for automatically generated release notes (strip contribution template artifacts from PR messages, generate and create a PR with the release notes doc that once merged, tags a new patch release and maybe even prepares a discuss post/announcement).
make the product (Neos CMS) more accessible for the typical target group of a wordpress homepage with content editing capabilities for the customer. This involves (roughly in order of importance):
easier installation on shared hosting, possibly independent of composer (yes, I know - but wordpress wouldn’t be so successful if it depended on a composer install though)
more options for base installations that just fulfill basic users’ core requirements (Roland wants to create a couple of templates, which is a great step! Templates to get people hooked on Neos)
providing a set of base content elements/node types that are well documented so they can be easily adjusted even by non-proficient web devs
(optional) interactive guide through the Neos backend for first-time users with something like http://bootstraptour.com/
as far as I understand, we need votable budget applications by August 30. So far, we only have a single budget application (ES CR); the remainder is a set of floating ideas without budget amounts or a budget owner.
So, if you want to make your ideas reality, please create a budget application post and link it here, with details on the amount of the budget, who will be the budget owner, and who will spend time on it if the budget is granted (gather a team for your topic).
I think that with the 28k in the piggy bank it would be interesting to see how many people/groups are stepping up with funding requests and which amount of money would still be missing. As a so-called “Longtime Supporter”, we really like it that the money is spent by the end of the year. I think that an additional crowdfunding would be OK if more funds were requested than needed. On the other hand, we must keep in mind that it’s always the more or less same group of ~25-30 agencies (including the agencies of you people that already do so much voluntary work) that take part in funding. Maybe (I’m not sure at all!) it would be better to concentrate on outreach for getting more longtime supporters. Part of the outreach could be a preview on planned changes for the next major versions.
Personally, my two favourites are the ES CR and Documentation.
One big missing thing in Neos is the possibility to roll back changes that someone made to content. Last week, we spent several hours trying to fix a site where an accidental move operation over 18k nodes ran into a timeout, leaving a part of the nodes at the new and the rest at the old location. As far as I understood, the new ES CR would enable to create mechanisms for rolling back changes.
On the other hand, the documentation has improved so much during this year that I assume granting additional funds will further stimulate having good documentation.
I’m looking forward to the individual proposals. Thanks everyone for your efforts!
i would like to see the budget going to these 3 things:
Make it easier for business people to try neos
Currently we don’t have a demo, which doesn’t need any installation. We should provide a demo instance, so anybody can try Neos with a few clicks.
I think this doesn’t eat much money. I maintain a demo instance in AWS, which costs me ~40 bucks a month. I can help here, if you which
Make the documentation even better
We have docs.neos.io and the documentation on readthedocs. In my experience, this confuse some people because they don’t know how to look at. So we should this be more clear.
Event Sourced CR
Personally i would love to see the Event Sourced CR to be finished. I think it could be that USP for neos. I don’t know any CMS/CMF which has this feature built in.
I’m happy if the CR stuff gets a big part of the budget.
Is the budget for the 5.0 and 5.1 release already included?
I’m also currently thinking about a SEO feature related budget, but I’m not sure if I’m able to put that into a full application until my holiday next week. But we also achieved a lot in the last 12 months and there was not too much feedback yet on possible improvements or further features. Maybe I’ll rather apply for something for Q1 2020.
Another possible topic would be the technical work on neos.io as this is currently going very slow right now. This is also a bit related to the demo that was already mentioned. @tschoeki what do you think?
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.
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
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 GitHub - neos/Neos.Demo: The Neos demo site package 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:
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?
