Proposal: remove restriction on developer category within discourse


#1

I think opening up the developers category has been brought up a few times. How about we vote until the next Stan meeting (Thursday) and we can take action then?

Just FYI, the voting results are public.

  • Open developers category (everyone can read and write)
  • Leave developers category as-is (everyone can read, only approved members can write)
  • Don’t care
  • Other (write in a suggestion)

0 voters


#2

If we decide to open up the category, I think these are the steps we should take in Discourse:

  • Add a “Stan Core Development Team” group; add the people listed as active developers on mc-stan.org to that group
  • Rename the Developers only category to “Stan Core Internal Discussions” or something similar (I think we want to un-nest it from the Developers category); set permissions so that it’s read/write for this new group
  • Open up the Developers category to everyone

#3

Wasn’t there a conversation about this on here about 2 weeks ago?

Has there been a problem other than Bob’s Stan 3 proposal thread, which definitely shouldn’t been more open because not all stakeholders could comment.

Edit to say: A private Dev-only category is useful. It’s rarely used, but all the issues I’ve seen raised in it couldn’t be raised on here in public. And a post here minimises email traffic/gets to everyone. Losing it would be inconvenient.

(For those who can’t see the category, it does not contain development discussions.)

Edit 2: Changing permissions on a private category to make it public should involve permission from everyone who posted in it and a careful check nothing sensitive was posted there. It would be better to start a new category and let the old one die.


#4

Yes, but no resolution. It was part of a thread. I’m just laying this out with the options and a path forward if we take the option to change permissions.

+1. To all of this! Exactly. It’s rarely used, but when used, it’s appropriate. And it’s not for development discussion.

Sorry, I must not have been clear.

I’m not suggesting opening up the private category. I am suggesting that the group that can access it should b restricted to only the people listed on the website and that it remains private. We currently give people who ask access to the developers category, which automatically grants access to the private subcategory.

We wouldn’t change it from private to public.


#5

For those who are interested in the reasons this category is as it is, said thread is here: Please keep development discussion open

Previous discussion around this point was here: Stan Governance

(Minor disclosure: I wouldn’t have access to that category under this proposal. I don’t think that’s a tragedy.)


#6

Currently we have a private dev category and a public dev category that users can’t post to. Is the goal here to make the public dev category one that users can post to? That seems fine. I don’t know why that involves the shuffle you suggest below but that’s ok.


#7

Yes.

You’re absolutely right. No need for the shuffle.

I was conflating a second thing: restricting the access to the private channel to just those on the core team.


#8

Isn’t that what the ‘developers-only’ category does?


#9

That was the original intention, but in practice, not quite.

The access to that subcategory is defined by the people within the “developers” group. As people request access to participate on the developers category, we just grant them access (which gives access to both). The “develeoprs” group is actually larger than just the core devs.


#10

Just a quick update: I added a “Stan_Development_Team” group to Discourse! I’ve put it off for long enough.


#11

Yes, you would. The “General” category is open.


#12

We discussed it at the Stan meeting today (10/26/2017). We decided to open it up to everyone to post.

We’ll rely on good forum etiquette and moderate discussions to threads on topic.

We will revisit this decision at the Stan meeting in a month.


#13

The developers category is now open.


#14

What precisely is the developer category for, now?


#15

Stan (code) development! Stuff like implementation details for Math, Stan, or the interfaces, code design decisions, new features and bugs, etc. The stuff that used to be on stan-dev.

The stuff that used to be in stan-users is everywhere else. That includes users reporting installation issues, modeling questions, most modeling implementation discussions. There’s a gray area in between that can go in either place.

Make sense? I think the stricter separation and purpose got lost when the users list became a number of categories in discourse.


#16

Sorry. Category of user. I’d there any reason for it to exist?


#17

Nope. We don’t have a single “user” category anymore.


#18

Thank you for doing this. My background is in software development. As someone who is mostly lurking and new to stan, I can’t give much back in the discussion of models. But I can help with ‘Developers’ questions.

My first day on the site a senior developer was trying to figure out how to use discourse. So I was excited to bitch in. I wrote up a long response answering each of his questions from my personal experience using discourse in other communities. Then I wanted to ensure I shode good faith. So I found documentation for each point. (fyi, There is surprisingly lital on what version of markdown is used. I eventually linked to the source code.) Only to discover that I could not post it as I was not a Developer.

There was an open question on whether pystan should interop with pandas. But now I know not to try and respond.

There is an ongoing discussion on testing, how much, when and where. I lurk/follow on the rust-lang infrastructure team. I thout I’d suggest reading some of the thoughts the rust-lang devs have on this, especially the “Not Rocket Science Rule”.

I just wanted to share some anecdotes from my experience. I would have posted earlier, but the dragon eats its own tail; the discussion of being more inclusive was not itself inclusive.

So thank you for opening this up. I understand that there are tradeoffs. I hope the experiment goes well.


#19

(I take this out of the context and answer specifically to these lines)

Hi, comments are always welcome and any discussion considering PyStan should be non-hostile. So even if the discussion has “ended”, please give your comment on subject.Z