The Peptide CommonsEst. May 2024
Independent. We sell nothing and are affiliated with no manufacturer or pharmacy. Every moderation action is logged in public
Meta · Feature requests · continued

Request: a per-category review queue posts 31–60

This is a continuation of a long topic, addressed by post number rather than by page. Start at post 1.

RH
revision_historyTL3Wiki editor11 Jun 2026 · edited#31

Duplicate requests: if several people request the same feature, the requests often get merged. Check whether your feature has already been suggested before posting.

0 likes 2mo
JI
j.ivaturiTL2 Moderator12 Jun 2026#32

Coming back to post #30, because the follow-up matters more than the original answer.

Feature scope: some requests are for the site itself (search, filtering, navigation). Some are for the documentation (new topics, different formats). Scope helps prioritise.

3 likes 2mo
M
microgramsTL2Regular12 Jun 2026#33
l.vermeulen, post #28: Thank you for the correction. I have edited my earlier post with a note rather than silently, so the thread still makes sense to read. The error was mine and it was the kind that comes from remembering a figure instead of looking it up. Go to post

post #32 answers the question as asked. The question underneath it is different.

Thank you for the correction. I have edited my earlier post with a note rather than silently, so the thread still makes sense to read. The error was mine and it was the kind that comes from remembering a figure instead of looking it up.

11 likes in reply to #28 2mo
AA
a.adeyemiTL2 Moderator13 Jun 2026#34

Community support: if other people support your request, they can reply with "+1" or "I would use that too". Widely-requested features are prioritised.

23 likes 1mo
ST
sterile_tableTL3Regular13 Jun 2026#35

Tradeoffs: every feature has a cost in maintenance and complexity. Acknowledging tradeoffs shows you have thought through the implications.

1 like 1mo
YE
y.eriksenTL2 Moderator14 Jun 2026#36

Having read the exchange above, I think I was wrong earlier in this topic and I want to say so plainly rather than quietly editing.

The correction was fair and I had been repeating something I had not checked carefully enough.

6 likes 1mo
WT
week_threeTL1Member14 Jun 2026#37
l.vermeulen, post #28: Thank you for the correction. I have edited my earlier post with a note rather than silently, so the thread still makes sense to read. The error was mine and it was the kind that comes from remembering a figure instead of looking it up. Go to post

post #36 is right about the mechanism and I think understates the practical bit.

Deprecation requests: if you think a feature should be removed or changed, that is also a request. Explain why you think it would improve the site.

16 likes in reply to #28 1mo
GB
g.bakkenTL2 Moderator15 Jun 2026#38

Worth separating two things that post #34 runs together.

Requests for platform and documentation features, with the reasoning that justifies them. If you think the site would be better with a feature, suggest it with enough detail that it is actionable.

31 likes 1mo
DV
dr.villanuevaTL3Physician15 Jun 2026#39

Picking up post #36: that is the part I would want checked first.

Use case: explain why you think the feature would help. "I would use this to..." makes the request concrete.

3 likes 1mo
SG
s.grimaldiTL2 Moderator16 Jun 2026#40

Requests for platform and documentation features, with the reasoning that justifies them. If you think the site would be better with a feature, suggest it with enough detail that it is actionable.

10 likes 1mo
GO
g.oyelaranTL2 Moderator16 Jun 2026#41
cannula_trace, post #10: post #9 answers the question as asked. The question underneath it is different. Tracking: staff will update the status of feature requests (under consideration, planned, implemented, declined). Checking back lets you know the fate of your suggestion. Go to post

Feature scope: some requests are for the site itself (search, filtering, navigation). Some are for the documentation (new topics, different formats). Scope helps prioritise.

0 likes in reply to #10 1mo
TK
t.kulkarniTL3Regular17 Jun 2026#42

I disagree with the reply above, and I think the disagreement is substantive rather than terminological.

The distinction being drawn does not survive when you look at the published data for this specific question. I would be glad to be shown wrong on this, because the version I am arguing against is more convenient.

19 likes 1mo
BF
b.friskTL2 Moderator17 Jun 2026#43

Worth separating two things that post #39 runs together.

Alternatives: if you have thought of a way the current site might already serve your need, mention it. It helps assess whether the feature is truly missing or just not obvious.

5 likes 1mo
BE
bench_entryTL3Regular18 Jun 2026#44

Use case: explain why you think the feature would help. "I would use this to..." makes the request concrete.

0 likes 1mo
DV
d.vestergaardTL2 Moderator18 Jun 2026#45
buffer_margin, post #15: post #14 answers the question as asked. The question underneath it is different. Duplicate requests: if several people request the same feature, the requests often get merged. Check whether your feature has already been suggested before posting. Go to post

Community support: if other people support your request, they can reply with "+1" or "I would use that too". Widely-requested features are prioritised.

0 likes in reply to #15 1mo
VT
vial_tableTL2Member19 Jun 2026#46

Picking up post #43: that is the part I would want checked first.

Effort estimation: some features are trivial to implement; others are substantial work. Staff will estimate effort when assessing whether a feature is feasible.

27 likes 1mo
SS
s.salgadoTL2 Moderator19 Jun 2026 · edited#47

Deprecation requests: if you think a feature should be removed or changed, that is also a request. Explain why you think it would improve the site.

8 likes 1mo
IL
integrator_logTL3Regular20 Jun 2026#48

Tradeoffs: every feature has a cost in maintenance and complexity. Acknowledging tradeoffs shows you have thought through the implications.

2 likes 1mo
KA
k.asanteTL2 Moderator20 Jun 2026#49
Tamburello, post #21: Use case: explain why you think the feature would help. "I would use this to..." makes the request concrete. Go to post

I read post #47 twice before replying, because I had assumed the opposite.

Tracking: staff will update the status of feature requests (under consideration, planned, implemented, declined). Checking back lets you know the fate of your suggestion.

0 likes in reply to #21 1mo
CO
c.okaforTL3Regular21 Jun 2026#50

This follows post #47 rather than contradicting it.

Duplicate requests: if several people request the same feature, the requests often get merged. Check whether your feature has already been suggested before posting.

0 likes 1mo
RP
r.petrovTL2 Moderator21 Jun 2026#51

I disagree with the reply above, and I think the disagreement is substantive rather than terminological.

The distinction being drawn does not survive when you look at the published data for this specific question. I would be glad to be shown wrong on this, because the version I am arguing against is more convenient.

0 likes 1mo
P
preregisteredTL3Research methods22 Jun 2026#52

On post #48 — agreed on the reasoning, with one qualification.

Feature scope: some requests are for the site itself (search, filtering, navigation). Some are for the documentation (new topics, different formats). Scope helps prioritise.

2 likes 1mo
YR
y.rahimiTL2 Moderator22 Jun 2026#53
t.varga, post #26: post #25 is right about the mechanism and I think understates the practical bit. Effort estimation: some features are trivial to implement; others are substantial work. Staff will estimate effort when assessing whether a feature is feasible. Go to post

Tracking: staff will update the status of feature requests (under consideration, planned, implemented, declined). Checking back lets you know the fate of your suggestion.

14 likes in reply to #26 1mo
AD
appeals_deskTL3Regular23 Jun 2026#54

Requests for platform and documentation features, with the reasoning that justifies them. If you think the site would be better with a feature, suggest it with enough detail that it is actionable.

28 likes 1mo
NV
n.vukovicTL2 Moderator23 Jun 2026#55

post #54 is right about the mechanism and I think understates the practical bit.

Tradeoffs: every feature has a cost in maintenance and complexity. Acknowledging tradeoffs shows you have thought through the implications.

0 likes 1mo
PN
plateau_notesTL2Regular24 Jun 2026 · edited#56

Worth separating two things that post #52 runs together.

Practical note that does not fit anywhere else. Whatever you conclude from this topic, write down what you did and when. The single most useful thing in your own records is not any individual result; it is that they are dated and consecutive.

0 likes 1mo
CH
c.haddadTL224 Jun 2026#57
RF
resistance_firstTL2Regular25 Jun 2026#58
s.salgado, post #47: Deprecation requests: if you think a feature should be removed or changed, that is also a request. Explain why you think it would improve the site. Go to post

Community support: if other people support your request, they can reply with "+1" or "I would use that too". Widely-requested features are prioritised.

21 likes in reply to #47 1mo
NS
n.stanescuTL2 Moderator25 Jun 2026#59

post #58 answers the question as asked. The question underneath it is different.

Duplicate requests: if several people request the same feature, the requests often get merged. Check whether your feature has already been suggested before posting.

2 likes 1mo
NH
n.haddadTL2 Moderator26 Jun 2026#60

Use case: explain why you think the feature would help. "I would use this to..." makes the request concrete.

9 likes 1mo