Daniel, I agree about the data/api versioning. I was mostly talking about features and capabilities. For example, we could spend the next year developing a visual table editor, implement support for unlimited table sizes, provide import/export from other table formats, introduce elaborate schema validation, and many other cool features. And after that year realize that users don't need this whole thing at all, or need something similar but very different. Or we could release one small, well defined, stable subset of that functionality, get feedback, and move forward.
Do you have any thoughts about the proposed data structure? On Mon, Jun 6, 2016 at 4:09 PM, Daniel Kinzler <daniel.kinz...@wikimedia.de> wrote: > Am 04.06.2016 um 18:47 schrieb Yuri Astrakhan: > > In line with the "release early, release often", we will not have any > > elaborate data editing interface beyond the raw JSON code editor for the > > first release. > > A word of caution about this strategy: this is great for user facing > things, but > it really sucks if you are creating artifacts, such as page revisions. You > will > have to stay compatible with your very first data format, and the second, > and > the third, etc, forever. Similarly, once you have an ecosystem of tools > that > rely on your API and data model, changing it becomes rather troublesome. > > So, for anything that is supposed to offer a stable API, or creates > persistent > data, "release early, release often" is not a good strategy in my > experience. A > lot of pain lies this way. Remember: wikitext syntax was once a "let's > just make > it work, we will fix it later" hack... > > -- daniel > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
