Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Working Group Meeting

15 views
Skip to first unread message

Cliff Shaffer

unread,
Nov 5, 2024, 11:26:21 AM11/5/24
to SPLICE Parson's Problems Working Group
Hello! To help the various SPLICE Working Groups make progress, we are planning to host (virtual) working group meetings during the off weeks for our SPLICE PI meetings. The time slot is alternate Thursdays at 2:00pm US Eastern time (UTC -5: sorry, yes, note that our clocks recently changed...).

Ideally, we will run two Working Group meetings each session, depending on the level of interest.

On Thursday, November 14, we will have a Parsons Problems Working Group meeting at 2:00pm US Eastern time. I hope to see you there if you can make it! We will use this Zoom link:


We will be discussing the current draft working toward an interchange standard. Please see: https://docs.google.com/document/d/1ZzEgS4_2SyS88fhWVp0041KmfWFnXBKgMWmPEDI7chw/edit?usp=sharing



Cliff Shaffer

unread,
Nov 11, 2024, 4:33:56 PM11/11/24
to SPLICE Parson's Problems Working Group
I hope that I will see some of you this Thursday at  2:00pm US Eastern time to talk about the Parsons Problem Interchange Format (or anything else that we want to talk about that is relevant). Please take a look at the working document:  https://docs.google.com/document/d/1ZzEgS4_2SyS88fhWVp0041KmfWFnXBKgMWmPEDI7chw/edit?usp=sharing
In particular, there is a list of open questions at the end of the document that I hope we can discuss. The list is shown below.

                                -- Cliff

  1. Open Questions

  1. What should this be called? I had previously assumed that the community consensus was that the term “Parsons problem” could be applied to any block reordering problem. But not everyone uses the term this way, some limiting it to only coding problems. What term should we use? Stick with Parsons problems? Or call it something else? (And say in appropriate places that this includes Parsons problems as a subset.)

  2. Should we have a simpler “DAG” representation for basic only-one-order solutions? Right now, using the DAG notation all keys need to be typed twice. A simpler format would allow authors merely to type the keys in the correct order.

  3. As currently written, specific context usage features (things not intrinsic to an exercise definition, but rather that depend on how the exercise is to be used) are deliberately left out of the spec. The idea here is that context would be given to the implementation system as part of system authoring and use of exercises, not as part of the PIF definition. But perhaps this is inconvenient to actual use. An alternative is to put tags into PIF that allow problem authors (or instructors modifying a problem definition for use in a given course) to specify these contextual features. So far, these features have been identified as falling into this category:

    1. Block numbering

    2. A fixed order given to all users of the exercise (which ideally is generated randomly, but identically to all users)

    3. The relative relationship between the drop zone for constructing the solution, and the block pool. The could reasonably be side-by-side, or one above the other.

  4. Backtick (`) is currently used to delimit and separate toggles and textboxes.

    1. Is backtick a good choice?

    2. What do we do to escape when the backtick is needed to be used inside one of the choices?

  5. As currently written, the DAG goes into a separate section from the block specification. Authors might like to combine the blocks specification with the DAG in some way. We can investigate supporting either of two options: (1) put the DAG closer to the blocks. (2) let the blocks list embody the DAG itself, perhaps by adding a tag to each block to specify the parent.

Cliff Shaffer

unread,
Nov 14, 2024, 3:26:50 PM11/14/24
to SPLICE Parson's Problems Working Group
Turns out that this was a really bad time to meet for most people. We will try again on December 12 at 2:00pm. Hopefully that is a better time of the semester for some of you, though I know that for one key person this is not a good time slot.

One good thing did come out of this. We now have a reasonable solution for Issue #4 above regarding the delimiter for toggle lines. I have updated the definition document.

Cliff Shaffer

unread,
Dec 4, 2024, 3:49:26 PM12/4/24
to SPLICE Parsons Problems Working Group
Reminder that we will have a Parsons Problems Working Group meeting next Thursday, December 12, at 2pm US Eastern time.

The current draft problem interchange format document can be found at: https://docs.google.com/document/d/1ZzEgS4_2SyS88fhWVp0041KmfWFnXBKgMWmPEDI7chw/edit?usp=sharing
Feedback welcome, whether you can come to the meeting or not.
Here are some particular outstanding issues that need to be settled:
  • Originally, I had proposed an "explicit" representation for ordered grading (originally, this was a dag definition, that has since been somewhat expanded). Since that original proposal, we introduced an "implicit" approach where each block can declare its dependency blocks. Should we also keep the "explicit" approach as an option for how to specify the order? Would anyone actually prefer to use the explicit approach rather than the implicit approach?
  • Do you like using the term "Parsons problems"? Or should we adopt some other term? If so, what would that other term be?
  • How can we handle the concept of a block with a "hole" in it for other blocks? How can we support block-based languages like BlockPy or Scratch?
  • What is our general stance on including within the problem specification standard support for context-dependent features? These tend to be things related to specific use cases for a problem, rather than description of the problem, that a given instructor might or might not want to use within a particular system. Examples include: block numbering/labeling; fixed order to how the blocks are presented; the relative relationship of the section of the interface that holds the pool of blocks to the section of the interface that blocks are dragged to to construct the answer; hints on how feedback is to be provided (like, whether to tell the student which is the first out-of-order block). The basic choices are to allow these to be specified within the standard (that an implementing system might choose to accept or ignore), or leave them to be directed to the implementing system in some other way.
        -- Cliff

Reply all
Reply to author
Forward
0 new messages