DNA 2.3.2 Review

General remarks

I have to provide the review in form of a text file since the deliverable written in MS Word cannot be open with the newest version of open source text editors. This fact poses a question if a project that suppose to backup the idea of open source should use closed source, commercial software to create unreadable documents...

38 pages is too much for the deliverable, it would strongly suggest to shorten the document, few suggestion follow. But reading the document with that in mind should also be done by the authors

The document describes different ways of providing and generating "marketing" content. But even the best website is of no use when people cannot find it. In this regard SEO is quite important. The websites must be not only user-friendly but also "robots-friendly". It could not find a word treating on this subject in the whole deliverable, did NA2 took any steps toward SEO? Another aspect in this regard is the keyword optimization of the web-pages, that is a process that leads to associating the webpage with a given keyword: a user type in "middelware" and has the EMI page on the first place in the search results. Any activities or plans on that? Should be reported.

The same is truth for the conferences and other events. The best conference is of no use when nobody is attending. For instance, what steps were undertaken in order to inform users about the EMI TC? (and don't say it has a micropage on the EMI webpage). We have already seen that before, conferences full of experts struggling to find at least one, real user among the participants. In this context also planing for the 2013 is important, so that you could say in the conference "see you next year" or "EMI experts/representatives will be on XYZ next year". The list of planned participations you included in the document could be use as a dissemination means.

I miss a clear strategy statement, I see a lot of descriptions of tactical moves (participation in conferences, preparation of dissemination materials, etc), but the goal these tactical moves are aimed at is not clearly stated. What comes closest to the point is the introduction in the 3rd chapter, but it is too descriptive in my opinion. The values you list should result from the strategy statement. Without clearly pointing out what you are aiming at it is hard to say if the proposed measures are the proper ones.

The problem of inreach is completely ignored here. (I might be wrong in attributing this activities to NA2). We are all the best EMI ambassadors, you should take care of us and help us to preach more effectively. This is important since EMI put together people from earlier-competing projects. Unless some serious work on the inreach is done, all the partners remain that way and will advertise their products and not EMI.

I could not identified any piece of content or information that would justified the presence "Use of Knowledge" in the deliverable title. No plans on that? If so, change the title. Otherwise provide content.

Detailed remarks

Page 4 (Table of Contents)

  • "Participation to" should be "Participation in", (please scan the whole document!)
  • all events should be listed in the same, consistent form, "Name, Place, Date", this is done for SC11 but not for ISC11 or Unicore Summit
  • "Introduction" is on the right hand side, and "1." is not on the proper place (too far right)

Page 6

  • far too much "describes" in the abstract -References are not provided in a consistent way:
a) some of the URLs end with / others don't b) PRACE abbreviation is explained, EGI or DCISS are not c) I wonder why the reference URL for DNA2.4.2 is much shorter that the reference to DNA1.3.2?

Page 7

  • IMHO it is not a good idea to use the NA2/3 abbreviation, it comes also letter in the document, "NA2 and NA3" should be used instead,
  • too much "enhance" in the summary, do some wording
  • the remark about the paid advertising and its inapplicability, is a dangerous one, I cannot see reason why e.g. add words in google should not be applicable. Google became a research tool nowadays.

Page 10

  • "a massive customer potential behind need to be" I don't understand this sentence
  • "by mean of channels like DCI oriented conferences", the word "mean" comes very very often in the document, but I am not sure if the usage is proper, especially when used with no article. I would suggest to check the proper usage, and avoid the construction when possible (for instance in the sentence above).

Page 11

  • "i.e. Ubuntu, Linux Mint", should be "e.g." probably
  • "decrease the number of platform to be supported", I guess I understand what you mean, but the argumentation is hard to follow: "EMI increases the number of supported platforms to decrease the number of platforms that need to be supported", rephrasing is advisable here.
  • "Case studies" is more about White or Blue papers I guess? The terms are well established (at least in business), I would suggest to use them. Furthermore later in the document there are no plans how to get those use cases, this should be explained (part of the working plan)

Page 12

  • "users that know what they are searching.", "users who know what they are searching for"
  • here comes the UMD release for the first time, I would not assume that the matter is known to all readers, perhaps you can make it clear by writing "EGI UMD (Universal Middelware Distribution)"

Page 13

  • I don't understand the reasons for getting so quite after the EMI release, this would be probably the best time to actually make some noise, all the efforts before the release will bring the users to a software which is (at least) one year old, nothing to be proud of. It should be other way round.
  • IMHO EMIR as a new product is worth of promoting more actively, there are some other EU (and others) projects dealing with a distributed infrastructures, e.g. EUDAT. They will need something like EMIR sooner or latter, we should make sure they know EMIR exists before they make up their minds
  • Also STS could be use as a good marketing vehicle

Page 15

  • remove 4.1., the technical details and experiences with a Liferay software are important and should be documented in some way (e.g. in twiki) but don't fit the deliverable content
  • "relevant to", should be "relevant for"
  • in DNA2.3.1 there were plans for RSS feed mentioned, I guess this is already in place, add the content
  • also the Google+ profile, I know it is new. But it was not mentioned in the previous deliverable (if I recall correctly). If you have any further of such a surprise eggs you should also provide the information on that. Workplans are to be discussed.

Page 20

  • "But events are also the occasion to enlarge the base of user", "The events also provide an opportunity to enlarge the user base", I guess I have encountered "base of user" later in the document, check it.
  • "events are the right mean for a face-to-face possibility to demonstrate the features of the products...", beside the "right mean" and strange grammar, the whole sentence is a repetition of the previous section.

Page 21

  • "The (..) workshop will be followed by a community conference, such of a test for a "middelware and technology providers"", don't understand this sentence, it starts so strange and is almost one paragraph long, rephrase, bring your point

Page 22

  • "These interviews intend..." too many "for" in this sentence,
  • I would suggest to provide a link to a page with links to all the interviews, so that the reader could type (or C&P) once
  • in 5.2.1 you write that the feedback and suggestions from the users are taken as an input for technical discussions in EMI, from the marketing point of view it will be a good idea to say that to the users, like "you can influence the EMI software", are there any plans on that? For now EMI has some, not very transparent, way of creating technical objectives. Making the process more transparent and inform users about the possibility would be beneficial. It is partly what the open source projects are all about.

Page 23 (and latter)

  • all the sections describing the conferences should follow the same naming convention: Conference, Place, Date. Adding IEEE to the conference name when appropriate is also a common practice.
  • all the presentation should be referenced in the same way, on this page they are listed with "-", full name, author affiliation and title, but even in this list some titles are put in \" and others not. There is also no affiliation for Paul Millar, etc. Latter we have contribution listed as bullet points, with abbreviated names, or without title. This should be cleaned.
  • the description of the conferences are way too long, you can provide a reference (in case the reader is really interested), in this document the reasons for EMI attending given event should be pointed out. I guess the description should not be longer than 4 sentences, followed by the description of EMI activities.
  • writing "Project Manager" or "Strategic Director" without a name is strange
  • all the links should be substituted by the references (e.g. Page 25, Page 26)
  • "brand new (materials, video)", it is enough to say "new (materials, video)" here
  • "partners to-be", they might not be happy to read such a sentence, "potential partners" sounds much better

Page 27

  • "individuate" is a strange word, "identify"?
  • the list of the planned events should be presented as a table, sorted by dates. Actually the table should be put somewhere in the wiki, so that all the project participants or potential partners could quickly check where the next opportunity to meet EMI is
  • UNICORE Summit, will take place at 30-31 May in Dresden

Page 29

  • "and two with disseminating messages with promotional purposes", don't understand the formulation
  • "REF to A0 poster", reference missing
  • "area on the website: REF", missing reference

Page 31

  • "EMI 1 released by EGI as UMD 1.0.0", I don't want to put my fingers in the wounds, but "as" is not the entirely true, "in" is probably more true
  • "and invaluable instrument in use on research community", "on"?
  • General remark: you touched a very important problem here, how to make sure that EMI middelware is used to do some real research (and is mentioned in the papers). Since EMI does not offer infrastructures, it is probably not attractive for most of the researchers, but there are also projects that plan do acquire some infrastructure and they could use EMI. Are there any plans from NA2 to retroactively work on this front and make sure that EMI is used and mentioned by the researchers? I guess it is partly NA1, or NA3 perhaps.

Page 32

  • general remark, it would be much better to create own tables to present the results instead of putting pictures. Pictures are not the proper way of presenting numerical results.
  • regarding the number of visitors, can you tell how many of them were actual human users (and not search engine robots)?

Page 33

  • "The first graph shows", which one is it? is it Figure 8? The references should be reviewed here. Latter in this page you have a Figure 5 (which I could not find),

Page 34

  • it is really hard to understand what the pictures are showing (e.g. Figure 9), beside putting the relevant data in own tables, it would be a good idea to use more descriptive figure captions

Page 35

  • Table captions are usually put above and not below the table
  • there is also the google PR metric, do you have any data on that? Value and steps undertaken to increase the value would be good here

Page 36 & 37

  • you miss targeted values of KNA2.2 and KNA2.3 KPIs, I should be stated so, reasons should be given and improvements should be proposed
  • "Number of packages...", should be "number of packages" -how do you measure the "posts in the web forum" metric? And why are you expecting such an increase on that?
  • why the package download number is not available? And why are you expecting an increasing trend on that?
  • "Conference speech", "speeches"?

-- JedrzejRybicki - 12-Jan-2012

This topic: EMI > WebHome > EmiDocuments > EmiDeliverables > DeliverableDNA232 > DNA232ReviewJR
Topic revision: r1 - 2012-01-12 - JedrzejRybicki
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback