> > While I appriciate the idea of automatically propagating API state from > instable/friend to stable after some time, there may also be less APIs > as a result.
We have fewer APIs already - lots of friend APIs, almost no new public APIs. It has been that way for years. Continuing to do what we've been doing will the same result. If you want more, something must change. > So probably there should be some group of people, e.g. QA > team, deciding on where APIs should be defined. Then an API should be > defined and reviewed, say version 0.1 (to express it's still early alpha > stage). > > This API should then be implemented and further discussed (You'll > probably see during implementation what can be handled better some other > way, or simply where the specification is incomplete, erroneous or just > unspecified). > > Another issue is still module splitting - bigger feature implementations > are often splitted into several modules, which need the ability to > privately access each other. This also results in some mismatch: > Sometimes it would be nice to be able to expose some APIs as > friend-only, while others are interesting for public usage. If it is interesting to another module, it is interesting for public usage. Whether the author wants responsibility for making it stable is a separate question :-) But, is the splitting for aesthetic or more meaningful reasons? > Therefore I'd prefer to: > - set up a community page for API request. This page may just explain, > what to do, e.g. create a Jira issue, which parameters tu use (should be > task or wish or ..., keywords, etc.); > - set up a responsible QA team; > - discuss the API on the dev list with interested members. > Review is necessary, for sure. If you want to force that to actually happen, a timeout is a good way. -Tim
