Skip to content

Conversation

@omajid
Copy link
Member

@omajid omajid commented Mar 19, 2021

I had trouble trying to navigate designs, so maybe an overview will help others find designs too.

Some designs are clearly marked with a title and PM/Dev assignments. Some subdesigns, unfortunately, are marked the same way. So we have trouble finding main vs sub-designs.

You can see a fully rendered version here.

@danmoseley
Copy link
Member

@terrajobst

@danmoseley
Copy link
Member

Thanks for doing this. Any reason you didn't do the table in markdown? Not sure we have much HTML in the repo. Markdown is easier to edit and diff.

@mhutch
Copy link
Contributor

mhutch commented Mar 19, 2021

This omits a lot of designs - many do not declare a PM or dev owner.

@omajid
Copy link
Member Author

omajid commented Mar 19, 2021

Any reason you didn't do the table in markdown?

Uh... I didnt' realize markdown supported tables directly. I am definitely going to fix this.

This omits a lot of designs - many do not declare a PM or dev owner.

Yes, that's true. I used git history to find some owners for some proposals and fix them up. I am going to try and fix up others too. I wanted to get this out for general feedback before I take care of all the details.

@omajid omajid force-pushed the design-index branch 12 times, most recently from 19ccc9a to 3f0eff7 Compare March 20, 2021 22:19
@omajid omajid marked this pull request as ready for review March 20, 2021 22:22
@omajid
Copy link
Member Author

omajid commented Mar 20, 2021

I don't really know the formal roles of many people at Microsoft. I tried to guess their roles and I probably got some wrong.

From reading the generated table, I think there might be some improvements we want to consider to the design template:

  • What release the design was/is going to be delivered into
  • Whether the design still active (was it, perhaps, obsoleted by other designs or considerations?)
  • Whether the design was fully implemented (or maybe abandoned?)

But we don't have that information in a machine readable way yet.

https://openjdk.java.net/jeps/0 and https://www.python.org/dev/peps/ might also serve as additional sources for inspiration.

@danmoseley
Copy link
Member

Re roles: in that table, Claire, Sourabh, Immo, Rich, Kathleen are PM's and the others are Devs.

Personally, I don't think it's necessary to distinguish them. We are quite fluid with who does what. Many designs only have one or the other. But I don't feel strongly either way.

I had trouble trying to navigate designs, so maybe an overview will help
others find designs too.

Some designs are clearly marked with a title and PM/Dev assignments.
Some subdesigns, unfortunately, are marked the same way. So we have
trouble finding main vs sub-designs.
@omajid
Copy link
Member Author

omajid commented Mar 24, 2021

Personally, I don't think it's necessary to distinguish them. We are quite fluid with who does what. Many designs only have one or the other. But I don't feel strongly either way.

Okay. I kept them in the original design files (since the design template asks for it), but the index now just shows Owners without distinguishing who does what.

@terrajobst
Copy link
Contributor

I'm ambivalent on this. On the one hand, I like the single file for Ctrl+F. On the other hand, it seems it's yet another thing that will go out of sync fast.

There are two ways we could address that:

  1. Add CI that validates that the index.md file links your document
  2. Use GitHub actions to automatically add the line to the index.md file upon merge (tricky, need to avoid triggering itself)

@danmoseley
Copy link
Member

my 2c. it seems easy enough to keep up to date periodically, and no big deal if it goes out of date for a while. and if nobody likes to fix it - we delete it 😄


**PM** [Rich Lander](https://github.com/richlander)

// FIXME: do these count as PMs/Devs?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PM, Dev, Dev, but I don't think it matters


**PM** [Rich Lander](https://github.com/richlander)

// FIXME: do these count as PMs/Devs?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PM,Dev Dev


**PM** [Rich Lander](https://github.com/richlander)

// FIXME: do these count as PMs/Devs?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PM, Dev Dev

@danmoseley
Copy link
Member

@terrajobst do you feel the distinction between dev and PM in the template is important? not all documents have both, and even if they do, the roles are blurred. I think the template ought to just prompt for a list of stakeholders or owners, whatever their roles. the key requirement is: include all stakeholders and record who they are!

@terrajobst
Copy link
Contributor

terrajobst commented Mar 24, 2021

seems easy enough to keep up to date periodically, and no big deal if it goes out of date for a while

Sure, let's try and see

do you feel the distinction between dev and PM in the template is important?

No. In fact, let's change the template and call it "owner". I'll fix that.

@terrajobst terrajobst merged commit 1c503a7 into dotnet:main Mar 24, 2021
@danmoseley
Copy link
Member

@omajid do you feel like a follow up change that merges Dev/PM into Owners? If not LMK and I can do it.

@omajid
Copy link
Member Author

omajid commented Mar 24, 2021

I am happy to do it, but it might take a few days.

@jeffhandley
Copy link
Member

I'm late to the review

@terrajobst Since we recently started adding documents into accepted that are actually in DRAFT status, I wonder if we could also adjust this index to correct the "proposed" vs. "accepted" problem by deemphasizing the folder and instead adding a draft/proposed/accepted/rejected state column to the index. What do you think?

@akoeplinger
Copy link
Member

We should probably update https://github.com/dotnet/designs#creating-a-proposal to add a step 3. Add your spec to INDEX.md

omajid added a commit to omajid/dotnet-designs that referenced this pull request Mar 28, 2021
Comment on lines +73 to +76
| 2021 | [Designs](accepted/2021/statics-in-interfaces/designs/README.md) | [Immo Landwerth](https://github.com/terrajobst) |
| 2021 | [Requirements](accepted/2021/statics-in-interfaces/requirements/README.md) | [Immo Landwerth](https://github.com/terrajobst) |
| 2021 | [Scenarios](accepted/2021/statics-in-interfaces/scenarios/README.md) | [Immo Landwerth](https://github.com/terrajobst) |
| 2021 | [Statics in Interfaces](accepted/2021/statics-in-interfaces/README.md) | [Immo Landwerth](https://github.com/terrajobst) |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Static in interfaces are split over multiple documents. It is not clear by looking at the index that all these 4 documents are for static in interfaces.

Copy link
Member Author

@omajid omajid Mar 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for catching this! Do you think it makes more sense to have a single entry for "Statics In Interfaces" or should we list the individual sub-designs with a prefix like "Statics In Interfaces": "Statics In Interfaces: Requirements", "Statics In Interfaces: Scenarios" and "Statics In Interfaces: Designs"?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recommend just a single entry for these design that are being spread over multiple documents--just pointing to the top-level README for them.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would make sense to have just a single entry for Statics in Interfaces. The top level Statics in Interfaces doc can have links to the other ones.

Copy link
Contributor

@terrajobst terrajobst Mar 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would opt for a process that can be easily generated with @omajid's update script. Leaving designs out is probably harder than, say, a prefix notation.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The script uses a heuristic to separate main designs from subdesigns: If the document lists a PM/Dev (soon Owner), then the document is treated as a main (or top-level) design.

For Statics In Interfaces, it sounds like the main design is accepted/2021/statics-in-interfaces/README.md and the rest are the components. If we removed PM/Dev from those documents, the scripts will just ignore them.

(I also think it makes sense to do anyway: there aren't separate Owners for the Design vs Requirements vs Scenarios, are there?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively, I can fix the script to ignore a certain level of nesting as sub-designs and only look for top-level documents.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants