Re: [rdf4j-dev] shoutouts to contributors?

["Bart Hanssens (BOSA)" <bart.hanssens@xxxxxxxxxxxx>]

Hi,

 

Good points, I like the idea on writing release notes together.

And to leave out the affiliation, to keep rdf4j neutral

(nothing to hide, but those who are really interested in the names of our employers,

can just resort to google or linkedin 😉)

 

Best regards

 

Bart

 

From: rdf4j-dev-bounces@xxxxxxxxxxx <rdf4j-dev-bounces@xxxxxxxxxxx> On Behalf Of Jeen Broekstra
Sent: donderdag 7 mei 2020 8:50
To: rdf4j developer discussions <rdf4j-dev@xxxxxxxxxxx>
Subject: Re: [rdf4j-dev] shoutouts to contributors?

 

 

 

On Thu, May 7, 2020 at 3:59 PM Håvard Ottestad <hmottestad@xxxxxxxxx> wrote:

Hi,

I think it would be great to simply mention everyone who has made a contribution. And non-committers who submit a bug fix could get their name next to that fix.

 

I like that.

 

I don’t know if it would be good or bad mentioning which companies are involved. Personally I think a lot more companies should be helping out, but I’m also a bit worried that RDF4J would get associated with the companies helping out instead a being vendor neutral. Then again that hasn’t stopped ReactJS from becoming one of the most popular frameworks or RocksDB from being the go to backend for building your own database.

 

Thinking about it, for simplicity and to avoid controversy, I I think it's easiest to leave out the affiilition, and just stick to individual names.

 

As for attributing features to core contributors like the ones reading this email....I’m a bit unsure. The time that goes into code review, discussions, CQ filing and release management are just as important for having RDF4J be a library that is out there and used by developers.

 

Yeah, perhaps just list the (active) core committers, but not necessarily tie them to specific features.

 

I have one suggestion though. Could we collaborate on the release notes for these major releases? Open a PR a week before so people can add their features. Bigger releases like this could easily be an a4 page of two with a leading summary. We could integrate some code examples and highlight some of the new features. Pointing to where the new features are documented would also be great.

 

Definitely! I would love that, I just never did it because I (quite wrongly apparently) assumed that no-one would be interested in working on that :)

 

I'm also open for suggestions for a better place/structure for the release notes. Currently it's all one big page - if we go for lengthier notes we should think about breaking that up.

 

Cheers,

 

Jeen