since quite some time, I was pondering how to get the Neos React rewrite out of alpha towards
a stable base. In this post, I am sharing my ideas about a crowdfunding effort.
On the one hand, I feel I can quite well estimate the time needed to fix issues we are already knowing.
On the other hand, I still feel quite a lot of issues are simply not yet known, as the new UI is
not really used in production yet.
That’s why I’d combine the crowdfunding with a “call for websites” - everybody who sponsored at least
5000 € can hand in one of his Neos websites along with a list of 3-5 areas to test specifically for. We’ll then test that website with the new UI and fix the issues we’re coming across.
Estimation of TODOs
- 10 PT -> implementing search and filtering in document tree
- 10 PT -> fixing the remaining issues declared as must-have or “main area of work” in https://github.com/neos/neos-ui/issues/687
- 30 PT -> Testing websites; fixing “unknown unknowns”, see below.
-> Total: around 50 PT currently known.
for everybody who crowd-funded at least 5000 €, he should be able (and suggested) to hand in a Neos
website, consisting of:
- a git repository (or zip file of the full distribution) of a Neos 3.0 or newer website. (the
upgrade to Neos 3.x is of course not included.)
- a Data/Persistent dump
- a DB dump (formatted in UTF-8, as it is the Flow default)
- a readme what other services and versions are needed (we can test only Elasticsearch
Redis, Beanstalkd) and how to start them.
- the website has to run through
- a list of 3-5 areas to test specifically for (e.g. specialities of the website)
- Note: if you created custom (ember-based) inspector editors, they have to be manually
ported to React; this is not covered here.
Thus, we’d have at max 10 projects which need to be tested (or less, if people want to spend less
than 5000€ and are thus not eligible for the project-uploading).
For these projects, we’ll fix as many bugs in the new UI as we can; and give a “status
description” what still would need to be done. We will not fix bugs regarding the
project setup, templating, CSS; … - i.e. we will NOT modify the project’s
source code; but we give feedback on maybe how to improve the project if needed.
After all, we want to improve the Neos UI and uncover and fix hidden bugs in there.
Project Setup / Hourly Rate / Accountability (how to ensure we get this project done)
I’d like to run the project “like a real project” and not “pro bono / we try to do as much as
we can but do not give any guarantees”; so that’s why I’d also like to use a hourly rate which is
comparable to real-world projects – Something between 100 and 120 €/hour is the rate I am aiming for.
- there are explicit deliverables with clear timelines and time-bounding-boxes
- we have an overall project schedule and “overall project management”.
- we guarantee to the people who sponsor money that we’ll get the React Neos UI done-done
in the specified timeframe (meaning “real-world-usable” in all the demo-projects we are knowing).
I think it makes lots of sense to share the work amongst the people who have been involved in the project so far etc. This would allow us to reach our goals quicker etc.
However, I am unsure how to solve the issue “accountability-wise”; so if Sandstorm collects the money
and gives the promise that we are “done” at the end, and other team members hand in invoices to sandstorm
based on a fixed hourly rate, then we (sandstorm) might need to cover losses etc; which wouldn’t be fair
Proposed solution regarding accountability
I suggest that we (at the end of the project) all get paid the same hourly rate;
i.e. if we go over budget, we would share the risk depending on how many hours have been worked on by whom.
This is a little difficult to control against; but we’ve just done a bigger project where this setup
worked quite nicely; and it seems fair to me.
That’s why I’d actually like to plan with a hourly rate of 120€/hour; meaning we’d have 52 days to spend
in total. If we “go over budget” and have to spend 65 days to get the project done, we’d be at an hourly
rate of around 96€/hour; which is still fine I think.
On an organizational level this would mean the following:
We are controlling the budget against a hourly rate of 120 €/hour
However, we only pay out 90 €/hour during the project lifetime; the remainder goes
to a “Risk Buffer” pot.
At the end of the project, the “risk buffer” is split amongst the project participants
in a way that everybody will have had the same hourly rate.
Only if we would end up with a hourly rate of less than 90 €, some people would need
to “pay back” some money…
Timeframe / Project Plan
- Funding until August 31st
- 1st September - 15th November: main development phase
- 4th October: start project testing of core feature sponsors
- 15th November - 30th November: further stabilization phase
- December 2017: Neos 3.3 LTS release with new UI included.
I’d like to start with the known issues first (i.e. 691 and 687); and when these are nearing completion,
we’ll do the testing of the different websites.
There will be weekly public status reports on Discuss; and everybody who is actively working on a topic
at a given time will join the daily standup meeting (which is also open to the public).
I need your feedback; what do you think about the idea
- a) in general
- b) the specifics of this idea in detail.
All the best,