CF Conventions
Uses and configuration choices for CF GitHub Discussions #289
Replies: 5 comments 4 replies
-
|
Thanks, Jonathan. This is test reply! |
Beta Was this translation helpful? Give feedback.
-
Polls can be useful for gathering opinions on the way to consensus -- but it makes sense to wait for a use case before turning it on. (really put this in as a way to test using the discussion as anything else ...) |
Beta Was this translation helpful? Give feedback.
-
|
Dear all The CF information management team met this afternoon, chaired by @ethanrd, and discussed Discussions.
Best wishes Jonathan |
Beta Was this translation helpful? Give feedback.
-
|
@japamment @feggleton Related to the standard name repository. As discussed at the meeting this today, the standard names data is large. GitHub has a limit of 1GB for the published size of the website, distinct from the repository size which is actually quite reasonable for the CF website. The last build of the cf conventions website was 858MB, with the current size of each standard name publication, I suspec there is space remaining for fewer than 10 standard name table publications before we hit this limit and will be unable to build/update the website. As a possible solution, we discussed using a single git repository and utilizing tags for the versioned tables. I have prepared an example of how this could work: https://github.com/DocOtak/cf_standard_names If you browse the code, you will notice that only the "current" version is browsable, the checked out version of this will never be larger than the current size of the most recent name table (currently aprox. 18MB). The different versions have all been tagged: https://github.com/DocOtak/cf_standard_names/tags though I was very sparse on the tag message. If for example if you wanted to see the name table in version 78, you can browse the code: https://github.com/DocOtak/cf_standard_names/tree/78 The different versions were loaded into the repository sequentially, git itself uses a delta compression for storage. The compressed version of the entire history of the standard names is only 2.2MB. A potential downside of this method is that only the current version of the name table can be hosted directly in github pages, so only the "current" version would have the html interface on the website, though all the previous ones continue to exist within the git history. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for this useful comment, Andrew @DocOtak. In order to keep the present discussion focussed on "Discussions", I have started a new discussion on how to keep the versions of the standard name table, and I have copied your comment above to it. I suggest carrying on with that topic there, instead of here. |
Beta Was this translation helpful? Give feedback.
-
|
Just to test: I have just deleted my previous "just checking in ...." comment. I think that @JonathanGregory's top post (or a copy/pasted version thereof) would be excellent as a pinned issue in the |
Beta Was this translation helpful? Give feedback.
-
|
Forgive me if this has already been covered, but I don't think I've seen it mentioned... Use of upvoting and selected emojis on postsOne aspect of the topic I think would be useful to clarify, formally, is the meaning of upvote and selected emojis in CF GitHub Discussions, because unlike with GitHub Issues, we have this 'upvote' option and I think we can put it to good use to help to provide a quick way for people to indicate their thoughts about a given comment, since not everyone has time to make a post but might want to acknowledge that they have read a post or have a certain sentiment. I think it could be useful to outline an intended meaning for the upvote, versus the 'thumbs up' and 'thumbs down' emoji, at least (but potentially more of the set of eight provided for any comment can be put to use). Namely, given that GitHub describes the upvote option as as an indicator that someone thinks a comment/topic is important:
the 'thumbs up (down)' can be seen as a way to indicate 'I (dis)agree with this comment/view' which is somewhat similar, but also quite different. For example, someone could think someone made a point that merits further discussion, but that they disagree with it, say. And 'thumbs down' use can help us to identify CF Conventions change/update proposals where someone isn't happy with something. So, before people start to use Discussions for CF in earnest, I think it would be useful for us to outline clearly a distinction that we'd advocate people use with the upvote and the thumbs up/down emoji. My suggestions for sentiments to encode in this wayOn those lines, I for one would really like a quick way to say any of the following, and propose these actions for that, as a starting point:
|
Beta Was this translation helpful? Give feedback.
-
|
Pertinently, when you comment GitHub seems to set it so that you have upvoted your own comment, so you start on a '+1' upvote count unless you remove it. I guess that makes sense under the scheme above, since obviously any comment someone raises is one they think is important 😄 |
Beta Was this translation helpful? Give feedback.
-
|
I like your suggestions, and agree with them. In particular, distinguishing between "I think this is important" (upvote) and "I agree" (thumbs up) is valuable, because then you can both upvote and thumbs-down a comment to indicate that while you think it's an important point, you disagree with the conclusion. |
Beta Was this translation helpful? Give feedback.
-
Welcome to CF Discussions!
This is a forum for community discussion of matters relating to CF. I have set it up, with help from @davidhassell, as decided in December by the CF governance panel, following earlier discussion, especially at the last annual meeting. As you can see, a GitHub Discussion doesn't look very different from an issue, but they offer various other facilities. Quoting from the documentation:
Now we've enabled it, please try using Discussions for all new announcements, comments, ideas and Q&A, instead of issues in repositories, so we can gather experience with it. We hope no-one will mind trying. When we've tried for a while, we can decide (by consensus, as usual) how to proceed.
When you open a new discussion, you have to choose a category for it. There are currently just three categories:
Announcements. The default GitHub Discussions setup is that only "maintainers" can make announcements, but we have changed it so that anyone can make one. The distinguishing feature of announcements is that they aren't expected to begin a discussion.
Questions and answers. This category is for asking questions about how to use CF as it is e.g. the meaning of a convention, the appropriate standard name for a quantity, why something isn't working as expected, where to find some information, how to make a proposal for change. A question invites answers. In the default GitHub Discussions setup, answers can be voted for and ordered by votes, like you see for instance in
stackexchange. We have disabled this facility, because of our impression that questions to CF generally don't receive many answers, so there's no need to vote on them, and also that the answer is sometimes arrived at by discussion involving several people.Comments and ideas. This category is for discussions about how CF could be improved, what's wrong with it, what its purposes should be, whether it could be managed better, etc. If you have a definite proposal for change, it's fine to open a new issue straight away, rather than starting a discussion, just as before i.e. in the
discussrepo for standard names and other vocabulary, thecf-conventionsrepo for conventions, and thecf-convention.github.iorepo for website and governance.The default GitHub Discussions setup has a "poll" category as well. We have disabled this because CF makes decisions by consensus, not by voting, so we've not had a need for polls up to now.
The category can be changed for an existing discussion. It seems likely that a Q&A discussion (about how CF is now) might sometimes get changed into an into a comment or an idea (for how CF should be changed). We'll see. A GitHub discussion can be converted into a GitHub issue. It is likely that this will happen if a discussion identifies a change that could be proposed, after having begun without a definite idea for change. Decisions and discussions about proposed changes will still be made in issues according to our existing rules.
As you see, the categories are functional, rather relating to the subject matter. It is useful to apply one or more of the following five labels to indicate the area of the discussion, in order to guide people who are searching the discussions for something relevant (you can filter by label):
conventions,vocabulary(standard names etc.),website,governanceorGitHub. Apply more than one label if it's unclear which is applicable. You will see that there are several other available labels. That is because these Discussions are hosted in the existingdiscussrepo, and those are the labels used for issues in this repo. When we've got used to Discussions, we can tidy this up.It would be useful if we could put explanatory text about labels in the entry box for a new discussion. You can create a form for new GitHub discussions in YaML, but I can't find a way to produce a text entry box like the one you get by default, with buttons for creating markdown, and most importantly with a preview capability. The
textareafield is for simple text entry. With these forms, it would also be possible to add labels automatically, but I think we would need a different category for every possible combination of labels. That would be extremely clumsy. However, perhaps there are better ways to do these things.I guess that, unlike issues, there won't be a need to close discussions. It doesn't really matter if the list of open discussions becomes long, whereas with issues this is a problem, because the issues are the changes we are actively considering. If there are too many of them open in the list, you can't easily get an overview. But we'll see.
I chose the "Comments and ideas" category for this item that you are reading, rather than categorising it as an announcement, because our setup is all open for discussion here. Please say what you think about the above.
Best wishes
Jonathan
Beta Was this translation helpful? Give feedback.
All reactions