[Replicant] How shall we Redmine?
Kurtis Hanna
Kurtis at riseup.net
Sat Aug 24 08:35:00 UTC 2019
Hello Replicants,
OSUOSL recently finished updating our Redmine to version 4.0.4. [0]
Now that it is completed, it might be worth it to have a discussion
about whether we want to make a few modification to our now up-to-date
Redmine instance since it is used so much by the Replicant project.
I should start by mentioning that I haven't interacted much with other
project's Redmine instances and very well might not understand the
benefits of doing things differently than Replicant has already done
with our instance, so please accept my opinions below as humble
suggestions only.
Here's a few topics that we should perhaps explore:
1) Projects and Subprojects
In Redmine we can create Projects and Subprojects. Up until now we have
only used a single Project which has the following modules enabled:
Wiki, Calendar, Time tracking, Gantt, Issue tracking, and Forums. I also
just enabled the News module on the Project, but feel free to disable it
seems unneeded.
Denis made a subproject of our main Replicant project called 'Replicant
infrastructure' in order for us all to see what a subproject in Redmine
looks like. We can use it as a temporary sandbox to test it out. Do you
guys think that having subprojects would help us organize ourselves
better on Redmine?
One concern I have about it is that, especially with the wiki module
enabled on subprojects, it would lead to data fragmentation.
For instance, I'm not sure if any problems are solved by having this wiki:
https://redmine.replicant.us/projects/replicant/wiki/ReplicantInfrastructure
duplicated, linked to, or moved to a Replicant Infrastructure Subproject
wiki here:
https://redmine.replicant.us/projects/replicant-infrastructure/wiki
I feel like our wiki guidelines regarding the naming of pages[1]
accomplishes the problem that a subproject wiki tries to solve, but
perhaps someone else can think of good reasons for us to have two wikis.
I could perhaps see a benefit of having a subproject with only the
issues and news enabled, but I haven't thought through the potential
data fragmentation issues that might arise by doing this as much.
Are any problems solved by having infrastructure issues listed in a
subproject instead of separated into its own Category on a unified
Redmine project? If filtering is the perceived benefit, it seems to me
that the filtering options for issues in our main Project are already as
granular as they can get. It even includes the ability to exclude any
Categories, including Infrastructure, that you don't want to see.
I seem to agree with this commenter's post on the subject, "[Redmine
subprojects] are generally used for large projects when there are clear
distinctions between both the groups of people working on different
areas [and clear distinctions] between those areas".
https://www.redmine.org/boards/1/topics/23075?r=23089#message-23089
Perhaps there will come a time to use subprojects, but it doesn't seem
like we have the need for them currently.
It is worth noting that the Redmine project themselves don't use
Subprojects: [2] https://www.redmine.org/projects
I should point out here that there is a redmine plugin[3] that adds the
ability to make multi-project issues.
2) Should we make it easier to find our web facing git repo?
The Redmine project seems to keep their projects's code in their redmine
instance via the repository module:
https://www.redmine.org/projects/redmine/repository
We have the Repository module turned off in our Redmine instance and
instead use the FSF's infrastructure to host our web viewable git repo
at git.replicant.us.
I'm in favor of continuing to use FSF's infrastructure to host our code,
but it does make it more difficult to find our code in our Redmine
instance than it is in Redmine instances that have a "Repository" tab
that links to their git repo.
We also don't seem to have any direct links to git.replicant.us on our
main wordpress site. I guess we sort of used to have these links before
our git atom feed broke (which we still need to remove).
Would it be good to add a direct link to git.replicant.us on the top
black banner of our main page where it says "Blog Wiki Tracker Forums"
and also, if OSUOSL can do it easily, in between "Projects" and "Help"
in the top left corner of all of the pages on our Redmine instance where
it says: "Home My page Projects Help"
The easiest way for new visitors to our main page to get to
git.replicant.us currently seem to require them to navigate to
ReplicantSourceCode [4] which take more clicks than it really ought to.
3) Plugins
There are a number of Redmine plugins that we should at least consider
adding. Here's a few of them:
Agile - https://www.redmine.org/plugins/redmine_agile
a) Displays Redmine Issues as task cards on an Agile board
Checklists: https://www.redmine.org/plugins/redmine_checklists
a) adds checklists
Emojis - https://www.redmine.org/plugins/redmine_emojibutton
a) Enables the use of emoji codes
b) Insert emojis with new button in issue/wiki editor
Lightbox - https://www.redmine.org/plugins/redmine_lightbox2
a) Lets users preview image, pdf and swf attachments in a lightbox
instead of requiring them to download images that aren't properly embedded.
People - https://www.redmine.org/plugins/redmine_people
a) Enables users avatars
b) Enables more granulated elastic permission rules,
c) Enables popup notification, reminders or warnings to a particular
page, group of users or all users, including recurring notifications, or
reminders
4) I've closed all the 4.2 related tickets since we are no longer
supporting that version. Is there a benefit to also closing Replicant
4.2 here [5] as was done with Replicant 1.5, 2.2, 2.3, and 4.0?
5) Should we remove PDF files of issues? Here's an example:
https://redmine.replicant.us/issues/1946.pdf I've noticed in the past
that these .pdf files end up getting found by search engines and makes
for an odd experience when one clicks on the link.
In Solidarity,
kurtis
[0] https://www.redmine.org/versions/151
[1]
https://redmine.replicant.us/projects/replicant/wiki/DeveloperGuide#Wiki-guidelines
[2] https://www.redmine.org/projects
[3] https://www.redmine.org/plugins/redmine_multiprojects_issue
[4] https://redmine.replicant.us/projects/replicant/wiki/ReplicantSourceCode
[5] https://redmine.replicant.us/versions/39/edit
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osuosl.org/pipermail/replicant/attachments/20190824/752b5b6f/attachment.asc>
More information about the Replicant
mailing list