Hi devs,
I don't think there is currently a process that is in place to handle
pull requests and I have the feeling that the way there are handled
today is a bit random.
There are usually comments sent out on each pull request but sometimes
it seems that some pull requests are going in sleep mode and it's not
clear who is in charge.
I would like to suggest that a process is put in place where it's
clear who is responsible for a pull request and a status is given to
the contributors that propose that pull request.
Something like:
Assigned developer: XXXX
Status:
New -> new pull request, not yet assigned
Assigned -> assigned to a developer, he is in charge of reviewing the
pull request and ask for modifications or accept it. The developer can
auto assign it to himself. If nobody does, we need to decide how they
will be taken into account.
ModificationsRequired -> for now rejected with comments. Contributor
needs to apply comments and then change back to Assigned for further
evaluation
VoteRequired -> there are no more comments, but a vote is required as
the changes to XWiki core are important
WaitingFinalAuthorization -> optional step for complex patches where
a additional authorization would be required (need to define who would
be the persons that give the authorization)
WaitingApplication -> there are no more comments and no changes or
vote required. The pull request can be applied and is waiting for a
developer to apply it
Abandoned -> contributors is abandoning the pull request (cannot do
the changes, no more time, etc..)
Rejected -> pull request is rejected (quality not enough, etc..)
Applied -> pull request is applied
What do you think ?
Ludovic
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hello,
Right now class property hints are not supported right in the core of
XWiki (though it's been mentioned as a possible future item of the
roadmap for AWM, see http://markmail.org/message/ltuphlj7bnnso2yb ).
Once this will be implemented, it will rely on i18n message keys so
that hints are localizables (same strategy as for class property
pretty names)
I'd like to start the discussion and see if we can agree on a
convention that would be used in the future when this module is
implemented.
The reason for this is I'm starting to work on a LDAP admin UI, and I
find that their field pretty names are not self-explanatory. It's not
a matter of expression, it's just the fact that what they describe
needs more explanation than what the pretty name can offer). In this
light, I'm planning on displaying such longer hints in this admin
section.
Right now the format for a pretty name is :
Space.Class_property=Pretty name
The format for a hint could be something like :
Space.Class_property.xHint=Hint
This would need escaping rules I think, since I believe
"property.xHint" is a valid property name
Note that I use "xHint" and not "hint" to be consistent with the form
standards class names. This can be discussed though.
WDYT ? Do you have other ideas ?
Jerome.
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
Hi devs,
Since statistics are disabled by default, I'm proposing to not bundle the
Statistics application by default. Admins who want to enable stats on their
would need to install it through the EM.
In addition, the Stats app's quality is not exactly perfect either and
performances are not that great so I think it makes sense to not promote it
too much either.
Last, since 5.3M2 the stats app is now visible in the Applications Panel
(for Admins), thus not bundling it by default seems even more needed now
IMO.
WDYT?
Thanks
-Vincent
Hi devs,
So this proposal appeared in some of my proposals but right now I created a
proper Proposal/Idea mail for it.
It's about having an 'Administer Page' section in the menus, similar to the
'Administer Wiki' and 'Administer Space' functionality.
The 'Administer Page' will be accessible to global admins, page creators
and users with (edit?/admin?) rights for the page.
>From what we currently have implemented it should contain the 'Rights
Editor' (?editor=rights) at page level.
In the future we could make 'Presentation', 'Page Elements' or 'Panel
Wizard' to be more granular and be set at Page level (have different panels
and style for just one page).
Some screenshots at
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/PageAdministration
Thanks,
Caty
Hi,
We are using mixed naming when referring to a document/page, not only on
different pages, but also in the same context (Rename step for example).
There is also an issue referring to this problem
XWIKI-5401<http://jira.xwiki.org/jira/browse/XWIKI-5401>and we need to
find an answer in order to move forward consistency.
So the question is which version we prefer: "Page" or "Document" ?
I'm voting +1 for "Page".
"Page" is more used IMO, especially in the "Space"/"Page" context.
"Page" is more general than "Document" and better fitted for a platform that
encapsulates all kind of content (not just documents).
Please cast your vote.
Thanks,
Caty
Hi,
According to the javadoc in XWikiDocument:
/**
* The last user that has changed the document's content (ie not object, attachments). The Content author is only
* changed when the document content changes. Note that Content Author is used to check programming rights on a
* document and this is the reason we need to know the last author who's modified the content since programming
* rights depend on this.
*/
private DocumentReference contentAuthorReference;
This means that objectadd or objectremove actions shouldn't change the content author as they do now.
I'm proposing that we fix this.
Do you see any issue?
Thanks
-Vincent
Hi devs,
Here's a proposal to move pages currently located in XE into platform modules:
* ColorThemes/*.xml --> xwiki-platform-colorthemes
* Main/Activity.xml --> xwiki-platform-activitystream-ui (move current xwiki-platform-activitytream into xwiki-platform-activitystream-api)
* Main/AllDocs.xml (and XWiki.Tableview, XWiki.Treeview, XWiki.OrphanedPages, XWiki.AllAttachments*, XWiki.DeletedDocuments, XWiki.DeletedAttachments and all pages used by those) --> new xwiki-platform-navigation module
* Main/RssFeeds.xml --> new xwiki-platform-help module or xwiki-platform-rss-ui module (see below)
* Main/SpaceIndex.xml --> xwiki-platform-navigation
* Main/Spaces.xml --> xwiki-platform-navigation
* Main/UserDirectory.xml --> xwiki-platform-user-ui
* Main/WebHome.xml --> xwiki-platform-dashboard-ui
* Main/WebRss.xml --> new xwiki-platform-rss-ui module, we would create a xwiki-platform-rss-api module too where we will move the feed plugin
* Main/Welcome.xml --> move to xwiki-platform-dashboard-ui since it's a dashboard gadget which we could consider as a default widget
* Sandbox/*.xml --> xwiki-platform-sandbox module (or xwiki-platform-help module)
* XWiki/XWikSyntax.xml --> xwiki-platform-help module
* XWiki/AttachmentSelector.xml --> xwiki-platform-user-ui or new xwiki-platform-attachmentselector module
* XWiki/ClassSheet, ClassTemplate, ObjectSheet, XWikiClasses,
* XWiki/GadgetClass.xml --> xwiki-platform-dashboard-ui
* XWiki/LiveTableResult*.xml --> new xwiki-platform-livetable module
* XWiki/MessageStreamConfig.xml --> new xwiki-platform-messagestream-ui module (and move xwiki-platform-message in xwiki-platform-message-api module)
* XWiki/RequestsStatus.xml --> xwiki-platform-administration module or remove from platform till we integrate it in the Admin as an admin tool somewhere since right now I think it's available in the Admin tools application
* XWiki/RequiredRightClass.xml --> since it's used in lots of other ui modules I'd propose to move it in java code as a class created on startup. Alternatively start creating a xwiki-platform-rights-ui module (or xwiki-platform-permission-ui module) and move it there
* XWiki/SharePage.xml --> not sure…. maybe in a xwiki-platform-share or xwiki-platform-sharepage module
* XWiki/TemplateProvider*.xml --> xwiki-platform-administration for the moment
* XWiki/WebHome.xml --> xwiki-platform-administration module
* XWiki/WebPreferences.xml --> xwiki-platform-administration module
WDYT?
Please try to tell me if you're ok for each line if you have time ;)
Thanks
-Vincent
Hi All,
i want to put a {{warning}} in the header of a page when a specific macro is
not contained. How can i do that. I tried in a Listener when the needed
Macro-Block is not contained with
doc.getXDOM().getRoot().addChild(new WordBlock("{{warning}}Warning
Text.{{/warning}}"));
context.getWiki().saveDocument(doc, context);
This not works. What is the correct way to manipulate the Document DOM on
Load?
Regards,
Matthias
--
View this message in context: http://xwiki.475771.n2.nabble.com/Inject-Warning-in-Page-when-Macro-in-Spac…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi All,
I want to create a component where i can overwrite a method of the component
from velocity or groovy script inside a wiki page. Its also fine if i can
"read" a groovy script to the component so i can use the defined logic.
Maybe i have to use a own programmed macro for that.
Is that possible? Do you use something similar somewhere?
Regards,
Matthias
--
View this message in context: http://xwiki.475771.n2.nabble.com/Overwrite-Method-of-Component-in-Velocity…
Sent from the XWiki- Dev mailing list archive at Nabble.com.