Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature/implementation matrix #34

Open
rlaemmel opened this issue Jun 12, 2017 · 0 comments
Open

feature/implementation matrix #34

rlaemmel opened this issue Jun 12, 2017 · 0 comments
Assignees

Comments

@rlaemmel
Copy link
Collaborator

cc @MarcelH91 @johanneshaertel @kevin-klein

There is one table that appears to be super-helpful for conveying our chrestomathy methodologically.

I suggest that this table is computed as HTML and added to he landing page.

The table's format:

  • columns: 22 concrete subfeatures grouped by 7 parent features
  • rows: approx. 10 selected implementations (see Section 2.2 of paper)
  • cells: checkmark whether an implementation implements a feature

Just for clarity:

  • An example for a group/parent feature is "Abstract syntax".
  • An example for a subfeature is "AST".

There are some important constraints on this table to make it user-friendly:

  • The groups should be ordered like the corresponding feature-model diagrams in the paper. This is taken care of by using this order also when persisting the feature model according to Explicit feature model #14
  • The subfeatures should be ordered like the leaf-nodes of the tiny feature trees in the paper. This is taken care of by using this order also when persisting the feature model according to Explicit feature model #14
  • The implementations should be ordered like they are introduced in the methodology section (even though this is not a precise statements because we don't work with names of implementations in the paper); the idea is that the endorsed implementations would thereby end up at the top of the table and so we could just copy and past the upper part of the table for the discussion in the paper. This is taken care of by having some sort of explicit order in a config file (next to feature model?). We will have "not so endorsed" implementations; they will show at the bottom and we will not copy them over into the paper.

This table is a great visual quality test for our methodology and thereby the coverage of the feature model or the "representativeness" of our implementations.

It looks like Simon may not manage this issue this week, but I file it anyway. Maybe Kevin can chime in and help on some issues or we (Johannes, Marcel) prototype the first version of the table manually (in LaTeX in that case). In the worst case, this table needs to go online past the deadline, which is actually also Ok because we may not have space to show the full table anyway; we may end up showing a fragment - which we would assemble manually.

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

No branches or pull requests

2 participants