Hi, I saw this big merge from Peter:
https://github.com/apache/incubator-commonsrdf/commit/20b0b000fc92a5699e0d79f9205cb62babe444bd This includes not just sorting out some BlankNode identifier stuff which we have already discussed at length (good) - but also a few other changes that got baked in, e.g. the return type of Graph.add(), and the removal of - Stream<? extends Triple> getTriples(Predicate<Triple> filter While I am not opposed to this removal (it's available as getTriples().filter()), I can't remember seeing these API changes being discussed (perhaps I missed something) - are we not keeping the way of working by pull requests and bugs? I would also prefer separate concerns as separate commits - I know from my own way of working that you find one thing when you work with another - but say getTriples(Predicate) has nothing with BlankNode identifiers directly, and so this should be a separate change request. I know we can follow and respond to commits@commonsrdf - but specially from git this often comes with 17 emails for a single merge, and so it's not good for anything but "something has changed". I propose that we work like this: API changes (e.g. signature modifications, change of semantics in javadoc) always as pull requests and/or Jira issues. Fixing typos, NullPointerExceptions and so on can just commit straight in. "Trying out something" should be done as a branch or personal fork. (Branch is preferred, as it allows others to modify your experiment) Semantic changes to the tests should be pull requests and Jira issues - as they are the other half of the contract. Changes to the simple implementation to conform with the tests can go straight in. Changes to the simple implementation that forces a new contract implication (typically something we haven't explored in detail yet) should be formalized as new javadoc/tests - and therefore raised as a separate discussion point by pull request or issue. Brand new implementation stuff should be done as a branch or pull request (there is probably not many of these for now). In general - a pull request is preferable to an issue, as an issue is an unbounded discussion, while a pull request is a concrete change request that can be tweaked. If we do it the Commons way - then any other committer can review and accept the pull request - although I think we should also allow room for the consensus to form - specially on API changes & design issues which we want to be considerate about. Views? -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons RDF (incubating) http://orcid.org/0000-0001-9842-9718
